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Avant-propos 



Ce livre a pour objectif de presenter les langages a objets et la 
programmation par objets d'une maniere generale et neanmoins 
precise. Le nombre de langages a objets existant aujourd'hui et 
leur diversite interdisent une etude exhaustive dans un ouvrage 
de cette taille. C'est pourquoi Ton s'est attache a identifier un 
nombre reduit de concepts de base, partages par de nombreux 
langages, et a illustrer ces concepts par des exemples concrets. II 
ne s'agit done pas d'apprendre a programmer avec un langage a 
objets (d'autres ouvrages, specialises, s'y emploient), mais de 
maitriser les principes de ces langages et les techniques de la 
programmation par objets. 

Ce livre s'adresse a des lecteurs ayant une experience de la 
programmation avec des langages «classiques» comme Pascal et 
Lisp, ou tout au moins une connaissance des principes de ces 
langages. II s'adresse done tout particulierement a des etudiants 
de second et troisieme cycle d'Informatique, ou d'autres 
disciplines dans lesquelles la formation a l'lnformatique aborde 
les langages de programmation evolues. Ce livre s'adresse 
egalement aux eleves des ecoles d'ingenieurs, aux chercheurs, 
aux enseignants, et plus generalement a tous ceux qui veulent 
comprendre les langages a objets. 



Plusieurs annees d'enseignement des langages a objets au 
D.E.S.S. Systeme et Communication Homme-Machine de 
l'Universite de Paris-Sud, et des conferences au Certificat C4 
d'Informatique Appliquee de cette meme Universite, m'ont 
conduit a la presentation des langages a objets adoptee dans ce 
livre : dans les deux cas, le faible volume horaire interdit tout 
apprentissage d'un langage particulier et invite a une 
presentation synthetique. II en resulte une grille d'analyse des 
langages a objets, largement emaillee d'exemples, dont 
l'ambition est de permettre au lecteur d'aborder la program- 
mation avec un langage a objets avec une vision claire et saine 
de l'univers de ces langages. 

Plusieurs personnes ont contribue a rendre ce livre plus clair 
et, je l'espere, facile d'acces : Thomas Baudel, Jean Chassain, 
Stephane Chatty, Marc Durocher, Solange Karsenty ont relu des 
versions preliminaires de cet ouvrage et apporte des commen- 
taires constructifs ; les membres du groupe Interfaces Homme- 
Machine du Laboratoire de Recherche en Informatique, par leur 
experience quotidienne de la programmation par objets, ont 
permis tout a la fois de mettre en evidence les realites pratiques 
de l'utilisation des langages a objets et de mettre a l'epreuve un 
certain nombre d'idees presentees dans ce livre. Marie-Claude 
Gaudel a egalement contribue a clarifier les notions liees au 
typage dans les langages de programmation en general et dans 
les langages a objets en particulier. Enfin, mon frere Emmanuel 
a realise l'ensemble des figures de cet ouvrage, et je lui en suis 
infiniment reconnaissant. 



Chapitre 1 
INTRODUCTION 



Les langages a objets sont apparus depuis quelques annees 
comme un nouveau mode de programmation. Pourtant la 
programmation par objets date du milieu des annees 60 avec 
Simula, un langage cree par Ole Dahl et Kristen Nygaard en 
Norvege et destine a programmer des simulations de processus 
physiques. Bien que de nombreux travaux de recherche aient 
eu lieu depuis cette epoque, l'essor des langages a objets est 
beaucoup plus recent. Ce livre essaie de montrer que les 
langages a objets ne sont pas une mode passagere, et que la 
programmation par objets est une approche generate de la 
programmation qui offre de nombreux avantages. 

1.1 LE CHAMP DES LANGAGES 

Situer les langages a objets dans le vaste champ des langages 
de programmation n'est pas chose facile tant le terme d'objet 
recouvre de concepts differents selon les contextes. Nous 
presentons ici plusieurs classifications des langages et situons les 
langages a objets dans ces differentes dimensions. 



2 Les langages a objets 



Classification selon le mode de programmation 

Cette classification presente les principaux modeles de 
programmation qui sont utilises aujourd'hui, c'est-a-dire les 
principaux modeles par lesquels on peut exprimer un calcul. 

• La programmation imperative, la plus ancienne, correspond 
aux langages dans lesquels l'algorithme de calcul est decrit 
explicitement, a l'aide d'instructions telles que 1' affectation, le 
test, les branchements, etc. Pour s'executer, cet algorithme 
necessite des donnees, stockees dans des variables auxquelles 
le programme accede et qu'il peut modifier. La formule de 
Niklaus Wirth decrit parfaitement cette categorie de langages : 

programme = algorithme + structure de donnees. 

On classe dans cette categorie les langages d'assemblage, 
Fortran, Algol, Pascal, C, Ada. Cette categorie de langages est 
la plus ancienne car elle correspond naturellement au modele 
d' architecture des machines qui est a la base des ordinateurs : 
le modele de Von Neumann. 

• La programmation fonctionnelle adopte une approche 
beaucoup plus mathematique de la programmation. Fondee 
sur des travaux assez anciens sur le lambda-calcul et 
popularisee par le langage Lisp, la programmation 
fonctionnelle supprime la notion de variable, et decrit un 
calcul par une fonction qui s'applique sur des donnees 
d'entrees et fournit comme resultat les donnees en sortie. De 
fait, ce type de programmation est plus abstrait car il faut 
decrire l'algorithme independamment des donnees. II existe 
peu de langages purement fonctionnels ; beaucoup intro- 
duisent la notion de variable pour des raisons le plus souvent 
pratiques, car l'abstraction complete des donnees conduit 
souvent a des programmes lourds a ecrire. Parmi les langages 
fonctionnels, il faut citer bien stir Lisp et ses multiples 
incarnations (CommonLisp, Scheme, Le_Lisp, etc.), ainsi que 
ML. 

• La programmation logique, nee d'une approche egalement 
liee aux mathematiques, la logique formelle, est fondee sur la 
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description d'un programme sous forme de predicats. Ces 
predicats sont des regies qui regissent le probleme decrit ; 
l'execution du programme, grace a l'inference logique, 
permet de deduire de nouvelles formules, ou de determiner si 
une formule donnee est vraie ou fausse a partir des predicats 
donnes. L'inference logique est tout a fait similaire aux 
principes qui regissent la demonstration d'un theoreme 
mathematique a l'aide d'axiomes et de theoremes connus. Le 
plus celebre des langages logiques est Prolog. 

La programmation par objets est-elle une nouvelle categorie 
dans cette classification ? II est difficile de repondre a cette 
question. La programmation par objets est proche de la 
programmation imperative : en effet, la ou la programmation 
imperative met 1' accent sur la partie algorithmique de la 
formule de Wirth, la programmation par objets met 1' accent sur 
la partie structure de donnees. Neanmoins, ceci n'est pas 
suffisant pour inclure la programmation par objets dans la 
programmation imperative, car l'approche des langages a objets 
s' applique aussi bien au modele fonctionnel ou logique qu'au 
modele imperatif. 

Classification selon le mode de calcul 

Cette classification complete la precedente en distinguant deux 
modeles d'execution d'un calcul : 

• Les langages sequentiels correspondent a une execution 
sequentielle de leurs instructions selon un ordre que Ton peut 
deduire du programme. Ces langages sont aujourd'hui les 
plus repandus, car ils correspondent a 1' architecture classique 
des ordinateurs dans lesquels on a une seule unite de 
traitement (modele de Von Neumann). Les langages a objets 
sont pour la plupart sequentiels. 

• Les langages paralleles permettent au contraire a plusieurs 
instructions de s'executer simultanement dans un programme. 
L'essor de la programmation parallele est du a la disponibilite 
de machines a architecture parallele. La programmation 
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parallele necessite des langages specialises car les langages 
usuels ne fournissent pas les primitives de communication et 
de synchronisation indispensables. Or il s'avere que le modele 
general de la programmation par objets est facilement 
parallelisable. Une classe de langages a objets, les langages 
d'acteurs, sont effectivement des langages paralleles. 

Classification selon le typage 

Cette classification considere la notion de type qui, dans les 
langages de programmation, est destinee a apporter une securite 
au programmeur : en associant un type a chaque expression 
d'un programme, on peut determiner par une analyse statique, 
c'est-a-dire en observant le texte du programme sans l'executer, 
si le programme est correct du point de vue du systeme de 
types. Cela permet d'assurer que le programme ne provoquera 
pas d'erreur a l'execution en essayant, par exemple, d'ajouter 
un booleen a un entier. 

• Dans un langage a typage statique, on associe, par une 
analyse statique, un type a chaque expression du programme. 
C'est le systeme de types le plus sur, mais aussi le plus 
contraignant. Pascal est l'exemple typique d'un langage a 
typage statique. 

• Dans un langage for tement type, l'analyse statique permet de 
verifier que l'execution du programme ne provoquera pas 
d'erreur de type, sans pour autant etre capable d'associer un 
type a chaque expression. Ceci signifie que les types devront 
eventuellement etre calcules a l'execution pour controler 
celle-ci. Les langages qui offrent le polymorphisme 
parametrique (ou genericite), comme ADA, sont fortement 
types. La plupart des langages a objets types sont fortement 
types, et notamment Simula, Modula3 et C++. 

• Dans un langage faiblement type, on ne peut assurer, par la 
seule analyse statique, que l'execution d'un programme ne 
provoquera pas d'erreur liee au systeme de types. II est done 
necessaire de calculer et de controler les types a l'execution, 
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ce qui justifie 1' appellation de langage a typage dynamique. 
Parmi les langages a objets, Eiffel est faiblement type car une 
partie du controle de types doit etre realisee a l'execution. 

• Dans un langage non type, la notion de type n'existe pas, et il 
ne peut done y avoir de controle sur la validite du programme 
vis-a-vis des types. Ainsi, Lisp est un langage non type, de 
meme que le langage a objets Smalltalk. 

La notion de type apporte une securite de programmation 
indispensable dans la realisation de gros systemes. De plus, 
comme nous allons le voir, elle permet de rendre l'execution 
des programmes plus efficace. C'est done une notion 
importante, et Ton peut constater que les langages a objets 
couvrent une grande partie de la classification ci-dessus. C'est 
ce critere qui va nous servir a structurer la suite de ce livre en 
distinguant d'un cote les langages types (fortement ou 
faiblement), d' autre part les langages non types. De nombreux 
travaux sont consacres actuellement a l'etude des systemes de 
types dans les langages a objets car le concept d'heritage, qui est 
l'un des fondements des langages a objets, necessite des 
systemes de types qui n'entrent pas dans les cadres etudies 
jusqu'a present. 

Classification selon le mode d 'execution 

Cette classification porte sur la facon dont l'execution du 
programme est realisee. Le mode d'execution n'est pas a 
proprement parler une caracteristique d'un langage, mais une 
caracteristique de V implementation d'un langage. 

• Les langages interpretes permettent a l'utilisateur d'entrer des 
expressions du langage et de les faire executer 
immediatement. Cette approche offre l'avantage de pouvoir 
tester et modifier rapidement un programme au detriment de 
la vitesse d'execution. Outre la vitesse d'execution, les 
langages interpretes ont generalement pour inconvenient 
d'etre moins surs, car de nombreux controles semantiques 
sont realises au fur et a mesure de 1' interpretation et non dans 
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une phase preliminaire de compilation. Beaucoup de langages 
a objets sont interpreted, et tirent avantage de cette apparente 
faiblesse pour donner une plus grande souplesse a l'execution 
des programmes. Ainsi, une modification ponctuelle d'un 
programme peut avoir des effets (controles) sur l'ensemble de 
l'execution, ce qui permet notamment de construire des 
environnements sophistiques pour la mise au point des 
programmes. 

• Les langages compiles necessitent une phase de compilation 
avant de passer a l'execution proprement dite d'un 
programme. Le but de la compilation est essentiellement de 
produire du code directement executable par la machine, done 
plus efficace. Pour cela, le compilateur utilise en general les 
informations qui lui sont fournies par le systeme de types du 
langage. C'est ainsi que la plupart des langages types sont 
compiles. De maniere generale, les langages interpretes sont 
plus nombreux que les langages compiles car la realisation 
d'un compilateur est une tache complexe, surtout si Ton veut 
engendrer du code machine efficace. Les langages a objets 
n'echappent pas a cette regie, et il existe peu de langages a 
objets compiles. 

• Les langages semi-compiles ont les caracteristiques des 
langages interpretes mais, pour une meilleure efficacite, ils 
utilisent un compilateur de maniere invisible pour l'utilisateur. 
Ce compilateur traduit tout ou partie du programme dans un 
code intermediaire ou directement en langage machine. Si le 
compilateur engendre un code intermediaire, c'est un 
interpreteur de ce code qui realisera l'execution du 
programme. Les langages a objets considered comme 
interpretes sont souvent semi-compiles, comme Smalltalk ou le 
langage de prototypes Self. 

Classification selon la modularity 

Cette derniere classification analyse la facon dont les langages 
permettent au programmeur de realiser des modules et 
d'encapsuler les donnees. La modularite et l'encapsulation 
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assurent une plus grande securite de programmation et 
fournissent la base de la reutilisation. 

• Absence de modularity : le programmeur doit, par des 
conventions de programmation et de nommage, prendre en 
charge la modularite. C'est notamment le cas de Pascal qui 
oblige a donner des noms differents a toutes les variables, 
procedures et fonctions globales, et ne permet pas de cacher 
des definitions autrement que par les regies de visibilite 
(procedures imbriquees), ce qui est insuffisant. Le langage C 
offre une modularite selon le decoupage du programme en 
fichiers, en permettant de declarer des variables ou fonctions 
privees a un fichier. En revanche, il n'offre pas la possibilite 
d'imbrication des procedures et fonctions. 

• Modularite explicite : certains langages offrent la notion de 
module comme concept du langage, que Ton peut composer 
avec d'autres notions. Par exemple, en Ada, la notion de 
« package » permet d'implementer un module, et se combine 
avec la genericite pour autoriser la definition de modules 
generiques (parametres par des types). 

• Modularite implicite : les langages a objets fournissent une 
modularite que Ton peut qualifier d'implicite dans la mesure 
ou celle-ci ne fait pas appel a des structures particulieres du 
langage. Au contraire, la notion de module est implicite et 
indissociable de celle de classe. 

La programmation par objets est une forme de program- 
mation modulaire dans laquelle l'unite de modularite est 
fortement liee aux structures de donnees du langage. Par 
comparaison, le langage Ada offre une modularite beaucoup 
plus independante des structures de donnees et de traitement du 
langage. La modularite est souvent consideree comme un atout 
important pour la reutilisation des programmes. De ce point de 
vue, les langages a objets permettent une reutilisation bien plus 
importante que la plupart des autres langages. 
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La programmation par objets comme un style 

De ce tour d'horizon, il faut conclure que la programmation 
par objets est plus une approche generale de la programmation 
qu'un type facilement classable. De fait, on voit aujourd'hui de 
nombreuses « extensions objets » a des langages existant : Pascal 
Objet, Lisp Objet, Cobol Objet, etc. Si certaines de ces extensions 
ne sont pas toujours un succes, il est un fait que les principes de 
la programmation par objets sont applicables dans un grand 
nombre de contextes. 



1.2 HISTORIQUE 

La figure 1 presente la genealogie des principaux langages a 
objets. On y distingue deux poles autour des langages Simula et 
Smalltalk. 

La famille Simula 

Le langage Simula est considere comme le precurseur des 
langages a objets. Developpe dans les annees 60 pour traiter des 
problemes de simulation de processus physiques (d'ou son 
nom), Simula a introduit la notion de classe et d'objet, la notion 
de methode et de methode virtuelle. Ces concepts restent a la 
base des langages a objets types et compiles, comme on le verra 
en detail dans le chapitre 3. Simula a ete cree dans la lignee du 
langage Algol, langage type de l'epoque dont Pascal s'est 
egalement inspire. 

Les langages de la famille Simula sont des langages imperatifs 
types et generalement compiles. L'interet d'un systeme de types 
est de permettre un plus grand nombre de controles semantiques 
lors de la compilation, et d'eviter ainsi des erreurs qui ne se 
manifesteraient qu'a l'execution. Typage et compilation sont 
deux concepts independants : on peut imaginer des langages 
types interpreted et des langages non types compiles. C'est 
neanmoins rarement le cas, car les informations deduites du 
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Figure 1 - Genealogie des principaux langages a objets 



typage permettent de generer du code plus efficace, ce qui 
encourage a compiler les langages types. 

Simula a inspire nombre de langages a objets. Certains d'entre 
eux sont maintenant largement plus connus et repandus que 
Simula, comme C++ et Eiffel. Plusieurs langages ont ete concus 
en ajoutant des concepts des langages a objets a un langage 
existant. Ainsi, Classcal et son descendant Object Pascal ajoutent 
des classes au langage Pascal, Modula3 est une revision majeure 
de Modula2 incluant des objets, C++ est construit a partir de C. 
Une telle approche presente avantages et inconvenients : il est 
commode de prendre un langage existant aussi bien pour les 
concepteurs que pour les utilisateurs car cela evite de tout 
reinventer ou de tout reapprendre. D'un autre cote, certains 
aspects du langage de base peuvent se reveler nefastes pour 
l'adjonction de mecanismes des langages a objets. 

La famille Smalltalk 

Dans les annees 70, sous l'impulsion d'Alan Kay, ont 
commence aux laboratoires Xerox PARC des recherches qui ont 
conduit au langage Smalltalk, considere par beaucoup comme le 
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prototype des langages a objets. De fait, c'est Smalltalk plutot 
que Simula qui est a l'origine de la vague des langages a objets 
depuis les annees 80. 

Smalltalk s'inspire de Simula pour les concepts de classes, 
d'objets et de methodes, mais adopte une approche influencee 
par Lisp pour ce qui concerne 1' implementation : Smalltalk est 
un langage semi-compile dans lequel tout est decide lors de 
l'execution. Comme dans Lisp, la souplesse due a l'aspect 
interprete de l'execution est largement exploitee par le langage. 

D'un point de vue conceptuel, Smalltalk introduit la notion de 
metaclasse qui n'est pas presente dans Simula. Cette notion 
permet de donner une description meta-circulaire du langage de 
telle sorte que Ton peut realiser assez simplement un 
interpreteur de Smalltalk en Smalltalk. Cet aspect meta- 
circulaire est egalement present dans Lisp, et dans de nombreux 
langages interpretes. Dans le cas de Smalltalk, les metaclasses 
sont accessibles a l'utilisateur de facon naturelle, et permettent 
de nombreuses facilites de programmation. L' introduction du 
modele meta-circulaire dans Smalltalk date de la premiere 
version du langage (Smalltalk-72). Les versions suivantes 
(Smalltalk-76 et Smalltalk-80) ont affine, ameliore et enrichi ce 
modele. D'autres langages inspires de Smalltalk sont alles plus 
loin dans cette direction, notamment ObjVLisp et Self. 

La meilleure preuve de la puissance de Smalltalk est 
l'ensemble des programmes realises en Smalltalk, et l'intense 
activite de recherche autour du langage, de ses concepts ou de 
ses langages derives. Parmi les realisations, il faut noter 
l'environnement de programmation Smalltalk, realise a Xerox 
PARC et implemente lui-meme en Smalltalk. Cet environ- 
nement, qui inclut un systeme d'exploitation, est le premier 
environnement graphique a avoir ete largement diffuse. 

Smalltalk a inspire de nombreux langages de programmation. 
Alors que Smalltalk est un langage natif, la plupart des langages 
qu'il a inspires sont realises au-dessus de Lisp. II s'avere que 
Lisp fournit une base au-dessus de laquelle il est facile de 



Introduction 1 1 



construire des mecanismes d'objets. On peut neanmoins 
regretter que dans nombre de cas le langage sous-jacent reste 
accessible, ce qui donne a l'utilisateur deux modes de program- 
mation largement incompatibles : le mode fonctionnel de Lisp 
et le mode de programmation par objets. Certaines incarnations 
de Lisp integrent les notions d'objets de facon presque native, 
comme Le_Lisp et CLOS (CommonLisp Object System). 

Autres families, autres langages 

Si les families Simula et Smalltalk representent une grande 
partie des langages a objets, il existe d'autres langages 
inclassables, d'autres families en cours de formation. 

Ainsi le langage Objective-C est un langage hybride qui 
integre le langage C avec un langage a objets de type Smalltalk. 
Plutot qu'une integration, on peut parler d'une coexistence 
entre ces deux aspects, car on passe explicitement d'un univers a 
l'autre par des delimiteurs syntaxiques. Les entites d'un univers 
peuvent etre transmises a l'autre, mais elles sont alors des objets 
opaques que Ton ne peut manipuler. L'interet de cette 
approche est de donner a l'utilisateur un environnement 
compile et type (composante C) et un environnement interprete 
non type (composante Smalltalk). Parmi les logiciels realises en 
Objective-C, le plus connu est certainement Interface Builder, 
1' environnement de construction d' applications interactives de 
la machine NeXT. 

Une autre famille est constitute par les langages de 
prototypes. Ces langages, au contraire des langages a objets 
traditionnels, ne sont pas fondes sur les notions de classes et 
d'objets, mais uniquement sur la notion de prototype. Un 
prototype peut avoir les caracteristiques d'une classe, ou d'un 
objet, ou bien des caracteristiques intermediaries entre les deux. 
D'une certaine facon, ces langages poussent le concept des 
objets dans ses derniers retranchements et permettent d'explorer 
de nouveaux paradigmes de programmation. 
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Une derniere famille est constitute de langages paralleles 
appeles langages d'acteurs. Dans un programme ecrit avec un 
tel langage, chaque objet, appele acteur, est un processus qui 
s 'execute de facon autonome, emettant et recevant des messages 
d'autres acteurs. Lorsqu'un acteur envoie un message a un 
autre acteur, il peut continuer son activite, sans se soucier de ce 
qu'il advient du message. Le parallelisme est done introduit par 
une simple modification du mode de communication entre les 
objets. Compare aux modeles de parallelisme mis en ceuvre dans 
d'autres langages, comme les taches de Ada, la simplicite et 
l'elegance du modele des acteurs est surprenante. Cela fait des 
langages d'acteurs un moyen privilegie d'exploration du 
parallelisme. 

1.3 PLAN DU LIVRE 

Ce livre a pour but de presenter les principes fondamentaux 
des langages a objets et les principales techniques de 
programmation par objets. II ne pretend pas apprendre a 
programmer avec tel ou tel langage a objets. A cet effet, les 
exemples sont donnes dans un pseudo-langage a la syntaxe 
proche de Pascal. Ceci a pour but une presentation plus 
homogene des differents concepts. 

Le prochain chapitre presente les principes generaux qui sont 
a la base de la programmation par objets. Les trois chapitres 
suivants presentent les grandes families de langages a objets : les 
langages a objets types, e'est-a-dire les langages de la famille de 
Simula (chapitre 3) ; les langages a objets non types, et en 
particulier Smalltalk (chapitre 4) ; les langages de prototypes et 
les langages d'acteurs (chapitre 5). Le dernier chapitre presente 
un certain nombre de techniques usuelles de la programmation 
par objets et une ebauche de methodologie. 

Une connaissance des principes de base des langages de 
programmation en general et de Pascal en particulier est 
supposee dans l'ensemble de l'ouvrage. Les chapitres 3 et 4 
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sont independants. Les lecteurs qui preferent Lisp a Pascal 
peuvent lire le chapitre 4 avant le chapitre 3. 



Chapitre 2 
PRINCIPES DE BASE 



Un langage a objets utilise les notions de classe et ^instance, 
que Ton peut comparer aux notions de type et de variable d'un 
langage tel que Pascal. La classe decrit les caracteristiques 
communes a toutes ses instances, sous une forme similaire a un 
type enregistrement (« record » Pascal). Une classe definit done 
un ensemble de champs. De plus, une classe decrit un ensemble 
de methodes, qui sont les operations realisables sur les instances 
de cette classe. Ainsi une classe est une entite autonome. Au lieu 
d'appliquer des procedures ou fonctions globales a des 
variables, on invoque les methodes des instances. Cette 
invocation est souvent appelee envoi de message. De fait, on 
peut considerer que Ton envoie un message a une instance pour 
qu'elle effectue une operation, e'est-a-dire pour qu'elle 
determine la methode a invoquer. 

On utilise souvent le terme d'objet a la place d'instance. Le 
terme « instance » insiste sur l'appartenance a une classe : on 
parle d'une instance d'une classe donnee. Le terme « objet » 
refere de facon generale a une entite du programme (qui peut 
etre une instance, mais aussi un champ, une classe, etc.). 
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Figure 2 



Illustration des notions de base 



^'heritage est la derniere notion de base des langages a 
objets : une classe peut etre construite a partir d'une classe 
existante, dont elle etend ou modifie la description. Ce 
mecanisme de structuration est fondamental dans les langages a 
objets ; il est decrit dans la section 2.3 de ce chapitre. 

La figure 2 decrit ces quatre notions de base, et introduit les 
conventions que nous utiliserons dans les autres figures. 



La notion d'objet ou instance recouvre toute entite d'un 
programme ecrit dans un langage a objets qui stocke un etat et 
repond a un ensemble de messages. Cette notion est a comparer 
avec la notion usuelle de variable : une variable stocke un etat, 
mais n'a pas la capacite par elle-meme d'effectuer des 
traitements. On utilise pour cela dans les langages classiques des 
sous-programmes, fonctions ou procedures. Ceux-ci prennent 
des variables en parametre, peuvent les modifier et peuvent 
retourner des valeurs. 



2.1 CLASSES ET INSTANCES 
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Dans un langage classique, on definirait par exemple un type 
Pile et des procedures pour acceder a une pile ou la modifier : 

• Emptier, qui prend une pile et une valeur a empiler ; 

• Depiler, qui prend une pile ; 

• Sommet, qui prend une pile et retourne une valeur. 

Cette separation entre variables et procedures dans les 
langages classiques est la source de nombreux problemes en ce 
qui concerne 1' encapsulation : pour des raisons de securite de 
programmation, on ne souhaite pas que n'importe quelle 
procedure puisse acceder au contenu de n'importe quelle 
variable. On est alors amene a introduire la notion de module. 
Un module exporte des types, des variables et des procedures. 
De l'exterieur, les types sont opaques : leur implementation 
n'est pas accessible. On ne peut done manipuler les variables de 
ce type que par 1' intermediate des procedures exportees par le 
module. A l'interieur du module, 1' implementation des types est 
decrite, et est utilisable par les corps des procedures. 

Ainsi, on peut encapsuler la notion de pile dans un module. 
Ce module exporte un type Pile, et les procedures Empiler, 
Depiler et Sommet, dont 1' implementation n'est pas connue de 
l'exterieur. Par cette technique, un utilisateur du module ne 
pourra pas modifier une pile autrement que par les procedures 
fournies par le module, ce qui assure l'integrite d'une pile. 

Le module constitue done le moyen de regrouper types et 
procedures, pour construire des types abstraits. Les langages 
Clu, Ada et ML, parmi d'autres, offrent de telles possibilites. 
Dans les langages qui n'offrent pas de modularite (Pascal, C, 
Lisp etc.), le programmeur doit faire preuve d'une grande 
rigueur pour reproduire artificiellement, e'est-a-dire sans aide 
du langage, l'equivalent de modules. 

L'approche des langages a objets consiste a integrer d'emblee 
la notion de variable et de procedures associees dans la notion 
d'objet. L'encapsulation est done fournie sans mecanisme 
additionnel. De meme qu'une variable appartient a un type dans 
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Figure 3 - La classe Pile et une instance 



un langage classique, dans un langage a objets un objet 
appartient a une classe. La classe est a la fois un type et un 
module : elle contient une description de type, sous forme de 
champs, ainsi qu'un ensemble de procedures associees a ce type, 
appelees methodes. 

Definir une classe 

On definira ainsi une classe Pile par : 

• un etat representant la pile (tableau, liste, etc.), constitue de 
champs. Pour une representation par tableau, on aura ainsi 
deux champs : le tableau lui-meme et l'indice du sommet 
courant. 

• la methode Empiler, qui prend une valeur en parametre. 

• la methode Depiler. 

• la methode Sommet, qui retourne une valeur. 

On cree des objets a partir d'une classe par le mecanisme 
d' instantiation. Le resultat de l'instanciation d'une classe est 
un objet, appele instance de la classe (voir figure 3). 
L'instanciation est similaire a la creation d'une variable d'un 
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type enregistrement. L' instance creee stocke un etat constitue 
d'une valeur pour chacun de ses champs. Les champs sont eux- 
memes des objets. Un certain nombre de classes sont predefinies 
dans les langages, telles que la classe des entiers, des caracteres, 
etc. 

L'encapsulation, c'est-a-dire l'acces controle aux objets, est 
assuree naturellement par les classes. Bien que differant d'un 
langage a l'autre, comme nous le verrons, on peut considerer 
dans un premier temps que les champs sont prives alors que les 
methodes sont publiques. Ceci signifie que les champs sont 
visibles uniquement depuis le corps des methodes de la classe, 
alors que les methodes sont visibles de l'exterieur. Nous allons 
maintenant decrire le mecanisme d'invocation des methodes. 

2.2 METHODES ET ENVOI DE MESSAGE 

Dans les langages a objets, les objets stockent des valeurs, et les 
methodes permettent de manipuler les objets. Ceci est 
comparable aux langages classiques, dans lesquels les variables 
stockent des valeurs et les procedures et fonctions permettent de 
manipuler les variables. Mais, contrairement aux procedures et 
fonctions qui sont des entires globales du programme, les 
methodes appartiennent aux classes des objets. Au lieu 
d'appeler une procedure ou fonction globale, on invoque une 
methode d'un objet. L'execution de la methode est alors 
realisee dans le contexte de cet objet. 

L'invocation d'une methode est souvent appelee envoi de 
message. On peut en effet considerer que Ton envoie a un objet, 
par exemple une pile, un message, par exemple « empiler la 
valeur 20 ». Dans un langage classique, on appellerait la 
procedure Empiler avec comme parametres la pile elle-meme et 
la valeur 20. 

Cette distinction est fondamentale. En effet, l'envoi de 
message implique que c'est le receveur (ici la pile) qui decide 
comment empiler la valeur 20, grace a la methode detenue par 
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sa classe. Au contraire, l'appel de procedure des langages 
classiques implique que c'est la procedure (ici Empiler) qui 
decide quoi faire de ses arguments, dans ce cas la pile et la 
valeur 20. En d'autres termes, la programmation imperative ou 
fonctionnelle privilegie le controle (procedures et fonctions) 
alors que la programmation par objets privilegie les donnees (les 
objets), et decentralise le controle dans les objets. 

Le corps d'une methode est execute dans le contexte de 
l'objet receveur du message. On a done directement et 
naturellement acces aux champs et methodes de l'objet 
receveur. C'est en fait seulement dans le corps des methodes 
que Ton a acces aux parties privees de l'objet, e'est-a-dire en 
general ses champs (les langages different sur la definition des 
parties privees). 

La definition conjointe des champs et des methodes dans les 
classes est a la base du mecanisme d'heritage, que nous allons 
maintenant decrire. 

2.3 L'HERITAGE 

La notion d'heritage est propre aux langages a objets. Elle 
permet la definition de nouvelles classes a partir de classes 
existantes. Supposons que Ton veuille programmer le jeu des 
Tours de Hanoi. On dispose de trois tours ; sur la premiere sont 
empiles des disques de taille decroissante. On veut deplacer ces 
disques sur l'une des deux autres tours en respectant les deux 
regies suivantes : 

• on ne peut deplacer qu'un disque a la fois ; 

• on ne peut poser un disque sur un disque plus petit. 

Le comportement d'une tour est similaire a celui d'une pile : 
on peut empiler ou depiler des disques. Cependant on ne peut 
empiler un disque que s'il est de diametre inferieur au sommet 
courant de la tour. 



Principes de base 2 1 



Si Ton utilise un langage classique qui offre ['encapsulation, 
on est confronte a 1' alternative suivante : 

• utiliser une pile pour representer chaque tour, et s' assurer 
que chaque appel de la procedure Emptier est precede d'un 
test verifiant la validite de l'empilement. 

• creer un nouveau module, qui exporte un type opaque Tour 
et les procedures Emptier, Depiler, et Sommet. 
L' implementation de Tour est une pile ; la procedure 
Empiler realise le controle necessaire avant d'empiler un 
disque. Les procedures Depiler et Sommet appellent leurs 
homologues de la pile. 

Aucune de ces deux solutions n'est satisfaisante. La premiere 
ne fournit pas d' abstraction correspondant a la notion de tour. 
La seconde est la seule acceptable du point de vue de 
l'abstraction mais presente de multiples inconvenients : 

• II faut ecrire des procedures inutiles : Depiler du module 
Tour ne fait qu'appeler Depiler du module Pile ; 

• Si Ton ajoute une fonction Profondeur dans le module Pile, 
elle ne sera accessible pour l'utilisateur de Tour que si Ton 
definit egalement une fonction Profondeur dans le module 
Tour comme on l'a fait pour Depiler ; 

• Le probleme est encore plus grave si Ton decide d'enlever 
la fonction Profondeur du module Pile : la fonction 
Profondeur de Tour appelle maintenant une fonction qui 
n'existe plus ; 

• II n'est pas possible d'acceder directement a 
1' implementation de la pile dans le module Tour, a cause de 
l'encapsulation. On ne peut pas ajouter la fonction 
Profondeur dans Tour sans definir une fonction equivalente 
dans Pile. 

Ce que Ton cherche en realite est la specialisation d'une pile 
pour en faire une tour, en creant un lien privilegie entre les 
modules Pile et Tour. C'est ce que permet l'heritage par la 
definition d'une classe Tour qui herite de Pile. 



22 Les langages a objets 



r 



pile 

sommet 



Pile 




Tour 



Empiler 
Depiler 
Sommet 



J 



Empiler 



Figure 4 - La classe Tour herite de la classe Pile 



Definir une classe par heritage 

Lorsqu'une classe B herite d'une classe A, les instances de B 
contiennent les memes champs que ceux de A, et les methodes 
de A sont egalement disponibles dans B. De plus, la sous-classe 
B peut : 

• definir de nouveaux champs, qui s'ajoutent a ceux de sa 
classe de base A ; 

• definir de nouvelle methodes, qui s'ajoutent a celles heritees 
de A ; 

• redefinir des methodes de sa classe de base A. 

Enfin, les methodes definies ou redefinies dans B ont acces 
aux champs et methodes de B, mais aussi a ceux de A. 

Ces proprietes montrent le lien privilegie qui unit B a A. En 
particulier, si Ton ajoute des champs et/ou des methodes a A, il 
n'est pas necessaire de modifier B. II en est de meme si Ton 
retire des champs et/ou des methodes de A, sauf bien sur s'ils 
etaient utilises dans les methodes definies ou redefinies dans B. 
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Dans notre exemple, on se bornera a redefinir la methode 
Empiler, pour faire le controle de la taille des disques et appeler 
la methode Empiler de Pile si l'operation est valide (voir figure 
4). Dans ce cas, on dira que Ton a specialise la classe Pile car on 
a seulement redefini l'une de ses methodes. Si Ton definissait 
de nouvelles methodes dans la classe Tour (par exemple 
initialiser la tour avec N disques de taille decroissante), on aurait 
enrichi la classe Pile. Ce simple exemple montre deja que 
l'heritage peut servir a realiser deux operations : la 
specialisation et l'enrichissement. 

L'arbre d'heritage 

Telle que nous l'avons presentee, la notion d'heritage induit 
une foret d'arbres de classes : une classe A representee par un 
noeud d'un arbre a pour sous-classes les classes representees par 
ses fils dans l'arbre. Les racines des arbres de la foret sont les 
classes qui n'heritent pas d'une autre classe. 

Si C herite de B et B herite de A, on dira par extension que C 
herite de A. On dira indifferemment : 

• B herite de A 

• B est une sous-classe de A 

• B derive de A 

• B est une classe derivee de A 

• A est une (la) superclasse de B 

• A est une (la) classe de base de B 

Dans les deux dernieres phrases, on emploie l'article defini 
pour indiquer que A est 1' antecedent direct de B dans l'arbre 
d'heritage. 

Certains langages imposent une classe de base unique pour 
toutes les autres, appelee souvent Objet. Dans ce cas, la relation 
d'heritage definit un arbre et non une foret. Par abus de 
langage, on parle dans tous les cas de V arbre d'heritage. 
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2.4 L'HERITAGE MULTIPLE 

L'heritage que nous avons defini est dit heritage simple car 
une classe a au plus une classe de base. Une generalisation de 
l'heritage simple, Vheritage multiple, consiste a autoriser une 
classe a heriter directement de plusieurs classes. 

Ainsi si la classe B herite de Al, A2, . . . An, on a les proprietes 
suivantes : 

• les champs des instances de B sont l'union des champs de 
Al, A2, ... An et des champs propres de B ; 

• les methodes definies pour les instances de B sont l'union 
des methodes definies dans Al, A2, ... An et des methodes 
definies dans B. B peut egalement redefinir des methodes de 
ses classes de base. 

L'arbre ou la foret d'heritage devient alors un graphe. Pour 
eviter des definitions recursives on interdit d'avoir des cycles 
dans le graphe d'heritage. En d'autres termes, on interdit a une 
classe d'etre sa propre sous-classe, meme indirectement. 

Cette extension, apparemment simple, cache en fait de 
multiples difficultes, qui ont notamment trait aux problemes de 
collision de noms dans l'ensemble des champs et methodes 
heritees. Certaines de ces difficultes ne pourront etre 
developpees que dans la description plus detaillee des chapitres 
suivants. 

Une difficulte intrinseque de l'heritage multiple est la gestion 
de l'heritage repete d'une classe donnee : si B et C heritent de A 
par un heritage simple, et D herite de B et de C, alors D herite 
deux fois de A, par deux chemins D-B-A et D-C-A dans le 
graphe d'heritage (figure 5). Faut-il pour autant qu'une 
instance de D contienne deux fois les champs definis dans A, ou 
bien faut-il les partager ? 
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Figure 5 - Deux interpretations de l'heritage multiple 



Selon les situations, on souhaitera l'une ou l'autre solution, 
comme le montrent les deux exemples suivants. 

Soit A la classe des engins a moteur, qui contient comme 
champs les caracteristiques du moteur. Soit B la classe des 
automobiles et C la classe des grues. D est done la classe des 
grues automobiles. Les deux interpretations de l'heritage 
multiple sont possibles : si Ton herite deux fois de la classe des 
engins a moteur, la grue automotrice a deux moteurs : l'un pour 
sa partie automobile, l'autre pour sa partie grue. Si Ton herite 
une seule fois de l'engin a moteur, on a un seul moteur qui sert 
a la fois a deplacer le vehicule et a manceuvrer la grue. 

Soit maintenant A la classe des objets mobiles, contenant les 
champs position et vitesse. Soit B la classe des bateaux, qui 
contient par exemple un champ pour le tonnage, et soit C la 
classe des objets propulses par le vent, qui contient un champ 
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pour la surface de la voile. D est alors la classe des bateaux a 
voile. Une instance de D a bien entendu une seule position et 
une seule vitesse, et dans ce cas il faut partager les champs de A 
herites par differents chemins. 

L'heritage multiple n'offre pas de reponse satisfaisante a ce 
probleme. La premiere interpretation correspond a une 
composition de classes, la seconde a une combinaison. Le 
mecanisme de l'heritage est certainement imparfait pour 
capturer a la fois les notions de specialisation, d'enrichissement, 
de composition et de combinaison. Mais l'heritage n'est pas le 
seul moyen de definir des classes ! L'un des pieges qui guettent 
le programmeur utilisant un langage a objets est la mauvaise 
utilisation de l'heritage. La question qu'il faut se poser a 
chaque definition de classe est la suivante : faut-il que B herite 
de A, ou bien B doit-elle contenir un champ qui soit une 
instance de A ? B est-il une sorte de A ou bien B contient-il un 
A ? Nous reviendrons au chapitre 6 sur la pratique de la 
programmation par objets, et en particulier sur ces problemes. 

2.5 LE POLYMORPHISME 

La notion de polymorphisme recouvre la capacite pour un 
langage de decrire le comportement d'une procedure de facon 
independante de la nature de ses parametres. Ainsi la procedure 
qui echange les valeurs de deux variables est polymorphe si Ton 
peut l'ecrire de facon independante du type de ses parametres. 
De facon similaire la procedure Empiler est polymorphe si elle 
ne depend pas du type de la valeur a empiler. 

Comme le polymorphisme est defini par rapport a la notion 
de type, il ne concerne que les langages types. On distingue 
plusieurs types de polymorphisme, selon la technique employee 
pour sa mise en ceuvre : 

• Le polymorphisme ad hoc consiste a ecrire plusieurs fois le 
corps de la procedure, pour chacun des types de parametres 
souhaites. C'est ce que Ton appelle souvent la surcharge : on 
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peut definir Echanger (Entier, Entier) et Echanger (Disque, 
Disque) de facon independante, de meme que Empiler (Pile, 
Entier) et Empiler (Pile, Disque). Ce type de polymorphisme 
est generalement resolu de facon statique (a la compilation). II 
utilise le systeme de types pour determiner quelle incarnation 
de la procedure il faut appeler, en fonction des types effectifs 
des parametres de l'appel. 

• Le polymorphisme d' inclusion est fonde sur une relation 
d'ordre partiel entre les types : si le type B est inferieur selon 
cette relation d'ordre au type A, alors on peut passer un objet 
de type B a une procedure qui attend un parametre de type A. 
Dans ce cas la definition d'une seule procedure definit en 
realite une famille de procedures pour tous les types inferieurs 
aux types mentionnes comme parametres. Si Entier et Disque 
sont tous deux des types inferieurs a Objet, on pourra definir 
les procedure Echanger (Objet, Objet) et Empiler (Pile, 
Objet). 

• Le polymorphisme parametrique consiste a definir un modele 
de procedure, qui sera ensuite incarne avec differents types. II 
est implemente par la genericite, qui consiste a utiliser des 
types comme parametres. Ainsi si Ton definit la procedure 
Echanger (<T>, <T>), on pourra l'incarner avec <T> = 
Entier ou <T> = Disque. On peut faire de meme pour Empiler 
(Pile, <T>). 

Ces trois types de polymorphisme existent dans divers 
langages classiques. En Pascal le polymorphisme existe mais 
n'est pas accessible a l'utilisateur ; on ne peut done pas le 
qualifier puisque sa mise en oeuvre est implicite. Par exemple les 
operateurs arithmetiques sont polymorphes : 1' addition, la 
soustraction, etc. s'appliquent aux entiers, aux reels, et meme 
aux ensembles. De meme, les procedures d'entree-sortie read et 
write sont polymorphes puisqu'elles s'appliquent a differents 
types de parametres. 

Ada offre un polymorphisme ad hoc par la possibilite de 
surcharge des noms de procedures et des operateurs. II offre 
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egalement un polymorphisme parametrique par la possibilite de 
definir des fonctions generiques. En revanche le 
polymorphisme d'inclusion est limite car tres peu de types sont 
comparables par une relation d'ordre. 

Le polymorphisme dans les langages a objets 

La definition du polymorphisme est dependante de la notion 
de type. Pourtant, tous les langages a objets ne sont pas types. 
Un langage a objets type est un langage a objets dans lequel 
chaque classe definit un type, et dans lequel on declare 
explicitement les types des objets que Ton utilise. Les langages 
a objets types fournissent naturellement le polymorphisme ad 
hoc et le polymorphisme d'inclusion. Certains langages offrent 
le polymorphisme parametrique mais il ne fait pas partie des 
principes de base presentes dans ce chapitre. 

Le polymorphisme ad hoc provient de la possibilite de definir 
dans deux classes independantes (c'est-a-dire n'ayant pas de 
relation d'heritage) des methodes de meme nom. Le corps de 
ces methodes est defini independamment dans chaque classe, 
mais du point de vue de l'utilisateur, on peut envoyer le meme 
message a deux objets de classes differentes. Ce polymorphisme 
ad hoc est intrinseque aux langages a objets : il ne necessite 
aucun mecanisme particulier, et decoule simplement du fait que 
chaque objet est responsable du traitement des messages qu'il 
recoit. 

La definition de plusieurs methodes de meme nom dans une 
meme classe ou dans des classes ayant une relation d'heritage 
est une forme de polymorphisme ad hoc qui n'est pas implicite 
dans les langages a objets, bien que la plupart d'entre eux 
offrent cette possibilite de surcharge. De plus, la redefinition 
d'une methode dans une classe derivee, avec le meme nom et les 
memes parametres que dans la classe de base, ne constitue pas 
une surcharge mais une redefinition de methode, comme nous 
l'avons vu dans la description de l'heritage (section 2.5). 
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Les langages a objets disposent egalement naturellement d'un 
polymorphisme d'inclusion que Ton appelle aussi 
polymorphisme d'heritage. En effet, la hierarchie des classes 
(dans le cas de l'heritage simple) induit un ordre partiel : si B 
herite de A (directement ou indirectement), alors B est inferieur 
a A. Toute methode de A est alors applicable a un objet de classe 
B : c'est ainsi que Ton a defini l'heritage des methodes. Le 
polymorphisme d'heritage nous permet done d'appliquer la 
methode Sommet de la classe Pile a un objet de la classe Tour, 
puisque Tour est une sous-classe de Pile. 

Le polymorphisme d'heritage s'applique egalement a 
l'heritage multiple, en definissant une relation d'ordre partiel 
compatible avec le graphe d'heritage de la facon suivante : une 
classe B est inferieure a une classe A si et seulement si il existe 
un chemin oriente de B vers A dans le graphe d'heritage. Le 
graphe etant sans cycle, on ne peut avoir a la fois un chemin 
oriente de A vers B et un chemin oriente de B vers A, ce qui 
assure la propriete d'antisymetrie. 

Le polymorphisme d'heritage s'applique non seulement au 
receveur des messages, mais egalement au passage de parametres 
des methodes : si une methode prend un parametre formel de 
classe A, on peut lui passer un parametre reel de classe B si B est 
inferieur a A. Ainsi la methode Empiler prend un parametre de 
classe Entier. On peut lui passer un parametre de classe Disque, 
si Disque herite de Entier. 

Liaison statique et liaison dynamique 

Le polymorphisme d'heritage interdit aux langages a objets 
un typage exclusivement statique : un objet declare de classe A 
peut en effet contenir, a l'execution, un objet d'une sous-classe 
de A. Les langages a objets sont done au mieux fortement types, 
ce qui a des consequences importantes pour la compilation de 
ces langages. Dans un langage a typage statique, le compilateur 
peut determiner quelle methode de quelle classe est 
effectivement appelee lors d'un envoi de message : on appelle 
cette technique la liaison statique. 
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Lorsque le typage statique ne peut etre realise, on doit avoir 
recours a la liaison dynamique, c'est-a-dire la determination a 
1' execution de la methode a appeler. La liaison dynamique fait 
perdre un avantage important des langages compiles : 
l'efficacite du code engendre par le compilateur. La liaison 
dynamique doit aussi etre utilisee dans les langages non types, 
car 1' absence de systeme de types interdit toute determination a 
priori de la methode invoquee par un envoi de message. Dans 
les deux cas, nous verrons les techniques employees pour rendre 
la liaison dynamique efficace. 

Les liens etroits entre polymorphisme, typage, et mode de 
liaison determinent en grande partie les compromis realises par 
les differents langages a objets entre puissance d'expression du 
langage, securite de programmation, et performance a 
l'execution. De ce point de vue, il n'existe pas aujourd'hui de 
langage ideal, et il est probable qu'il ne puisse en exister. 

2.6 LES METACLASSES 

Nous avons defini jusqu'a present la notion d'objet de facon 
assez vague : un objet doit appartenir a une classe. Certains 
langages permettent de considerer une classe comme un objet ; 
en temps qu'objet, cette classe doit done etre l'instance d'une 
classe. On appelle la classe d'une classe une metaclasse (voir 
figure 6). 

La description que nous avons donnee d'une classe ressemble 
effectivement a celle d'un objet : une classe contient la liste des 
noms des champs de ses instances et le dictionnaire des 
methodes que Ton peut invoquer sur les instances. La liste des 
champs d'une metaclasse a done deux elements : la liste des 
noms de champs et le dictionnaire des methodes. 
L'instanciation est une operation qui est realisee par une classe ; 
e'est done une methode de la metaclasse. 

Une metaclasse peut egalement stocker d'autres champs et 
d'autres methodes. Ainsi, l'arbre d'heritage etant une relation 
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objets 1 1 

Figure 6 - La notion de metaclasse 



entre les classes, chaque classe contient un champ qui designe sa 
classe de base (represente par les fleches grises epaisses dans les 
figures). Une methode de la metaclasse permet de tester si une 
classe est sous-classe d'une autre classe. 

Plusieurs modeles de metaclasses existent. Le plus simple 
consiste a avoir une seule metaclasse (appelee par exemple 
Metaclasse). Le plus complet permet de definir arbitrairement 
des metaclasses. Cela autorise par exemple la redefinition de 
l'instanciation ou l'ajout de methodes de classes (definies dans 
la metaclasse). Un modele intermediate, celui de Smalltalk-80, 
prevoit exactement une metaclasse par classe. L'environnement 
de programmation se charge de creer automatiquement la 
metaclasse pour toute classe creee par le programmeur. Ce 
dernier peut definir des methodes de classes, qui sont stockees 
dans le dictionnaire de la metaclasse. Cette approche rend les 
metaclasses pratiquement transparentes pour le programmeur, et 
offre un compromis satisfaisant dans la plupart des applications. 
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Dans tous les cas, la notion de metaclasse induit une regression 
a l'infini : en effet, une metaclasse est une classe, done un objet, 
et a done une classe ; cette classe a done une metaclasse, qui est 
un objet, etc. Cette regression est court-circuitee par une boucle 
dans l'arbre d'instanciation. Par exemple, la classe Metaclasse 
est sa propre metaclasse. 

Les metaclasses ont deux applications bien differentes. La 
premiere est de permettre une definition meta-circulaire d'un 
langage et de rendre accessible ses propres structures 
d'execution. On appelle cela la reification. Cette propriete existe 
egalement en Lisp et permet d'ecrire tres simplement un 
interprete Lisp en Lisp. Un langage reifie permet egalement de 
construire facile ment des moyens d' introspection pour aider a 
la mise au point des programmes : trace des envois de message 
et des invocations de methodes, trace des changements de valeur 
des variables, etc. 

La deuxieme application des metaclasses est de permettre la 
construction dynamique de classes. Prenons l'exemple d'une 
application graphique interactive dans laquelle l'utilisateur peut 
creer de nouveaux objets graphiques utilisables comme les 
objets primitifs (cercles, rectangles, etc.). Chaque nouvel objet 
graphique, lorsqu'il est transforme en modele, donne lieu a la 
creation d'une nouvelle classe. Cette nouvelle classe est creee 
par instanciation d'une metaclasse existante. En l'absence de 
metaclasses, il faudrait d'une facon ou d'une autre simuler ce 
mecanisme, ce qui peut etre fastidieux. 

Disposer de metaclasses dans un langages a objets signifie que 
Ton peut dynamiquement (a l'execution) definir de nouvelles 
classes et modifier des classes existantes. Cela interdit done tout 
typage statique, et e'est la raison pour laquelle les metaclasses ne 
sont disponibles que dans les langages non types. Certains 
langages types utilisent neanmoins implicitement des 
metaclasses, en autorisant par exemple la redefinition des 
methodes d'instanciation. II est egalement possible de definir 
des objets qui jouent le role des metaclasses pour la 
representation, a l'execution, de l'arbre d'heritage. Mais la 
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pleine puissance des metaclasses reste reservee aux langages non 
types. 



Chapitre 3 

LANGAGES A OBJETS 

TYPES 



Ce chapitre presente les langages a objets types, dont Simula est 
l'ancetre. Ce dernier etant peu utilise aujourd'hui, ce sont les 
langages plus recents C++, Eiffel et Modula3 qui nous serviront 
de base. La premiere version de C++ a ete definie en 1983 par 
Bjarne Stroustrup aux Bell Laboratories, le meme centre de 
recherches oil sont nes Unix et le langage C. Eiffel est un 
langage cree a partir de 1985 par Bertrand Meyer de Interactive 
Software Engineering, Inc. Modula3 est une nouvelle version de 
Modula developpee depuis 1988 au Systems Research Center de 
DEC sous l'impulsion de Luca Cardelli et Greg Nelson. 

Nous utilisons pour les exemples un pseudo-langage dont la 
syntaxe, inspiree en grande partie de Pascal, se veut intuitive. 
Nous donnons ci-dessous la description de ce langage sous 
forme de notation BNF etendue, avec les conventions suivantes : 

• les mots cles du langage sont en caracteres gras ; 

• les autres terminaux sont en italique ; 
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• les crochets indiquent les parties optionnelles ; 

• la barre verticale denote 1' alternative ; 

• les parentheses servent a grouper des parties de regies ; 

• + indique la repetition au moins une fois ; 

• * indique la repetition zero ou plusieurs fois ; 

• les indicateurs de repetition peuvent etre suivis d'une 
virgule ou d'un point-virgule qui indique le separateur a 
utiliser lorsqu'il y a plus d'un element dans la liste ; 

::= ( classe I methode ) + 

::= id-els = classe [id-els + >] { 
[champs champs + ] 
[methodes methodes" 1 "] 

} 

::= id-champ +> : type ; 

::= procedure id-proc (param*') ; 
I fonction id-fonc (param*') : type ; 

::= id-els I entier I booleen 

tableau [ const .. const ] de type 

id-param + > : type 

procedure id-cls. id-proc (param*') bloc 
fonction id-cls. id-fonc (param*'): type bloc 

{ [decl+] instr*: } 

id-var + > : type ; 



prog 
classe 



champs 
methodes 

type 

param 
methode 



I 



I 



bloc 
decl 
instr 



var 
id 



= var := expr 

I [var.]id-proc (expr*-) 

I tantque expr-bool faire instr 

I si expr-bool alors corps [sinon instr] 

I pour id-var := expr a expr faire instr 

I retourner [expr] 

I bloc 

::= id(.id-champ)* I var [expr] 

::= id-var I id-param I id-champ 



Langages a objets types 37 



expr ::= var I const 

I [var.]id-fonc (expr*-) 

I expr ( + 1-1*1/) expr 

expr-bool : := expr ( < I > I = I * ) expr 

I expr-bool ( et I ou ) expr-bool 

I non expr-bool 



Pour completer cette description, il convient de preciser que 
les commentaires sont introduits par deux tirets et se poursuivent 
jusqu'a la fin de la ligne. 



3.1 CLASSES, OBJETS, METHODES 
Definir une classe 

La notion de classe d'objets est une extension naturelle de la 
notion de type enregistrement. En effet, une classe contient la 
description d'une liste de champs, completee par la description 
d'un ensemble de methodes. 

Notre classe Pile peut s'ecrire : 

Pile = classe { 
champs 

pile : tableau [1 ..N] de entier; 
sommet : entier; 
methodes 

procedure Empiler (valeur: entier); 
procedure Depiler (); 
fonction Sommet () : entier; 

} 

La declaration d'un objet correspond a l'instanciation : 
p1 : Pile; 

L'invocation des methodes d'un objet utilise l'operateur 
point (« . »), qui permet traditionnellement l'acces a un champ 
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d'un enregistrement. On peut done considerer que les methodes 
se manipulent comme des champs de l'objet : 

p1. Empiler (10); 
p1 .Empiler (15); 
p1 .Depiler (); 

s := p1 .Sommet (); --svautIO 

Cette notation indique clairement quel est le receveur du 
message (ici pi), la methode invoquee, et ses parametres. 
Comme l'envoi de message necessite imperativement un 
receveur, on ne peut invoquer les methodes autrement que par 
cette notation pointee : 

Emp i ler (10) 

n'a pas de sens car on ne connait pas le receveur du message, 
sauf s'il y a un receveur implicite, comme nous le verrons plus 
loin. 

Cette meme notation pointee permet d'acceder aux champs de 
l'objet : 

p1 pile [5]; 

Les regies de visibilite empechent generalement un tel acces aux 
champs. Comme nous l'avons vu au chapitre 2, les champs sont 
d'un acces prive tandis que les methodes sont d'un acces 
public. Ceci signifie que les champs d'un objet sont accessibles 
seulement par cet objet, alors que les methodes sont accessibles 
par tout objet grace a l'envoi de message. 

Definir des methodes 

La declaration d'une classe contient les en-tetes des methodes. 
Nous allons decrire leurs corps de facon separee. Pour cela, 
nous utiliserons la notation classe. methode qui permet une 
qualification complete de la methode. En effet, deux methodes 
de meme nom peuvent etre definies dans deux classes 
differentes. Rappelons que cela constitue la premiere forme de 
polymorphisme offerte par les langages a objets, le 
polymorphisme ad hoc. 
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Selon les langages, la facon de declarer les corps des methodes 
varie. La notation que nous avons choisie est inspiree de C++. 
Eiffel adopte une autre convention qui consiste a mettre les 
declarations de methodes dans un bloc associe a la classe ou 
elles sont definies, ce qui pourrait etre transcrit de la facon 
suivante dans notre pseudo-langage : 

Pile = classe { 

procedure Empiler (valeur : entier) { 
-- corps de Empiler 

} 

-- etc. 

} 

La notation qualifiee que nous avons adoptee ici permet de 
separer la declaration de la classe de la declaration des corps des 
methodes, mais les deux mecanismes sont strictement 
equivalents. 

Dans notre exemple, si Ton omet les tests de validite des 
operations (pile vide, pile pleine), on a les definitions de corps 
de methodes suivantes : 

procedure Pile. Empiler (valeur: entier) { 
-- attention : pas de test de debordement 
sommet := sommet + 1 ; 
pile [sommet] := valeur; 

} 

procedure Pile.Depiler () { 

-- attention : pas de test de pile vide 
sommet := sommet - 1 ; 

} 

fonction Pile. Sommet () : entier { 
retourner pile [sommet]; 

} 

Une methode est toujours invoquee avec un objet receveur, 
qui sert de contexte a son execution. L'acces aux champs de 
l'objet receveur (pile et sommet dans notre exemple) se fait en 
mentionnant directement leurs noms. 
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Pour etre plus precis, les entites accessibles depuis une 
methode sont : 

• l'objet receveur, 

• les champs de l'objet receveur, 

• les methodes de l'objet receveur, 

• les parametres de la methode, 

• les variables locales de la methode, 

• les objets declares de facon globale au programme. 

Les champs des objets et les parametres etant eux-memes des 
objets, on peut invoquer leurs methodes. Pour illustrer cela, 
supposons l'existence d'une classe Fichier et ecrivons de 
nouvelles methodes pour la classe Pile (ces methodes doivent 
etre ajoutees a la declaration de la classe Pile) : 

procedure Pile.Ecrire (sortie : Fichier) { 

pour i := 1 a sommet faire sortie. Ecrire (pile [i]); 

} 

procedure Pile.Vider () { 

tantque sommet > 0 faire Depiler (); 

} 

Pile.Ecrire invoque la methode Ecrire du parametre sortie. 
Elle ecrit sur ce fichier l'ensemble des elements de la pile. Nous 
supposons ici que Ecrire est une methode de la classe 
Fichier. Pile.Vider invoque la methode Depiler sans la qualifier 
par un receveur, ce qui semble contraire a ce que nous avons dit 
plus haut. Mais ici on est dans le contexte d'un objet receveur 
de classe Pile, qui devient le receveur implicite de Depiler (voir 
figure 7). C'est par un mecanisme identique que sommet 
represente le champ sommet de l'objet receveur du message. 

La pseudo-variable moi 

Bien que l'objet receveur soit implicite en ce qui concerne 
l'acces aux champs et aux methodes, il est parfois necessaire de 
le referencer explicitement, par exemple pour le passer en 
parametre a une autre methode. Selon les langages, il porte le 
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0Vider 



pile 

sommet 



lr„ m ^£y„jfy r , D epj|er ( ) { 



Pile 

Vider ( ) { 
tant que sommet> 0 faire 
- Depiler ( ); 



Figure 7 - Acces aux champs et aux methodes. 
Les fleches hachurees represented l'invocation de methode 



nom reserve de « self » (Modula3, mais aussi Smalltalk), 
« Current » (Eiffel), « this » (C++). Nous l'appellerons « moi ». 
Moi n'est pas a proprement parler un objet, mais une fafon de 
referencer le receveur de la methode en cours d'execution. On 
utilise pour cela le terme de pseudo-variable. 

L'exemple suivant illustre l'utilisation de moi. Les classes 
Sommet et Arc permettent de representer un graphe. Un sommet 
est relie a un ensemble d'arcs, et un arc relie deux sommets. 



Sommet = classe { 
champs 

-- representation des arcs adjacents 
methodes 

procedure Ajouter (a : Arc); 

} 

Arc = classe { 
champs 

depart, arrivee : Sommet; 
methodes 

procedure Relier (s1, s2 : Sommet); 
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Ecrivons le corps de la methode Relier de la classe Arc : 

procedure Arc. Relier (s1, s2 : Sommet) { 
depart := s1 ; 
arrivee := s2; 
sl.Ajouter (moi); 
s2.Ajouter (moi); 

} 

Cet exemple montre qu'il est indispensable de pouvoir 
referencer explicitement le receveur du message dans le corps 
de la methode invoquee : c'est l'arc qui recoit le message Relier 
qui doit etre ajoute aux sommets si et s2. 

On peut egalement utiliser la pseudo-variable moi pour 
qualifier les champs et les methodes locales, mais cela n'apporte 
rien sinon une notation plus lourde. La methode Vider de la 
classe Pile pourrait ainsi s'ecrire comme suit : 

procedure Pile. Vider () { 

tantque moi.sommet > 0 faire moi.Depiler (); 

} 

Les classes primitives 

Nous avons utilise pour definir la classe Pile un champ de 
type entier et un champ de type tableau, considerant ces types 
comme predefinis dans le langage. Le statut de ces types 
predefinis varie d'un langage a 1' autre. En general, les types 
atomiques (entier, booleen, caractere) ne sont pas des classes et 
on ne peut en heriter. Les types structures comme les tableaux 
sont parfois accessibles comme des classes generiques. 

On peut toujours construire une classe qui contient un champ 
d'un type predefini. Malheureusement, a moins de disposer de 
mecanismes de conversion implicite entre types atomiques et 
classes, on ne peut utiliser ces classes de facon transparente. 

Par exemple, si Ton definit la classe Entier, contenant un 
champ de type entier, comme suit : 
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Entier = classe { 
champs 

valeur : entier; 
methodes 

procedure Valeur (v : entier); 

} 

procedure Entier. Valeur (v : entier) { 
valeur := v; 

} 

et si Ton change le type entier par la classe Entier dans la classe 
Pile, on ne peut plus ecrire 

p1 .Empiler (10); 

car 10 est une valeur du type predefini entier, et non un objet de 
la classe Entier. Sans mecanisme particulier du langage, il faut 
ecrire : 

v : Entier; 
v.Valeur (10); 
p1 .Empiler (v); 

La difference de statut entre types atomiques et classes resulte 
d'un compromis dans l'efficacite de 1' implementation des 
langages a objets types. Cette difference ne pose que peu de 
problemes dans la pratique, bien qu'elle soit peu satisfaisante 
pour 1' esprit. 

3.2 HERITAGE 

Nous allons maintenant presenter comment est mis en ceuvre 
l'un des concepts de base des langages a objets : l'heritage. 
Nous allons pour cela presenter les deux principales utilisations 
de l'heritage, la specialisation et l'enrichissement. 

Specialisation par heritage 

Nous definissons maintenant une sous-classe de la classe Pile, 
la classe Tour. Rappelons qu'une tour est une pile dont les 
valeurs sont decroissantes. 
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Tour = classe Pile { 
methodes 

procedure Initialiser (n : entier); 

fonction PeutEmpiler (valeur : entier) : booleen; 

procedure Empiler (valeur : entier); 

} 

L'heritage est mentionne dans l'en-tete de la declaration 
(comparer avec la declaration de la classe Pile). La procedure 
Initialiser empile n disques de tailles decroissantes : 

procedure Tour. Initialiser (n : entier) { 
sommet := 0; 

pour i := n a 1 faire Empiler (i); 

} 

Initialiser invoque la methode Empiler, qui est redefinie dans 
la classe Tour. Definissons maintenant les corps des methodes 
PeutEmpiler et Empiler : 

fonction Tour. PeutEmpiler (valeur : entier) : booleen { 
si sommet = 0 

alors retourner vrai; 

sinon retourner valeur < Sommet (); 

} 

La methode PeutEmpiler reference le champ sommet de sa 
classe de base ainsi que la methode Sommet definie egalement 
dans la classe de base. Elle teste si la valeur peut etre empilee, 
c'est-a-dire si la tour est vide ou sinon si la valeur est plus petite 
que le sommet courant de la tour. Empiler utilise PeutEmpiler 
pour decider de l'empilement effectif de la valeur : 

procedure Tour.Empiler (valeur : entier) { 
si PeutEmpiler (valeur) 

alors Pile. Empiler (valeur); 

sinon erreur.Ecrire ("impossible d'empiler"); 

} 

On suppose ici l'existence d'un objet global erreur, de la 
classe Fichier, qui permet de communiquer des messages a 
l'utilisateur grace a sa methode Ecrire. 
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Empiler (valeur: entier) { 



■,,,, rr ,,,, r ,,,, rr ,,. Pile. Empiler (valeur); 
} 

V J 

Figure 8 - Specialisation de la methode Empiler 

L'appel de Pile.Empiler (valeur) merite quelques explications. 
La classe Tour est une specialisation de la classe Pile, c'est-a- 
dire que Ton a simplement redefini une methode de la classe 
Pile. Dans cette situation, la methode redefinie a souvent besoin 
de referencer la methode de meme nom dans la classe de base. 
Si Ton avait ecrit 

Empiler (valeur) 

on aurait provoque un appel recursif, puisque Ton est dans le 
corps de la methode Empiler de la classe Tour. La notation 

Pile.Empiler (valeur) 

permet de qualifier le nom de la methode appelee. Comme Tour 
herite de Pile, la methode Empiler de Pile est accessible dans le 
contexte courant, mais elle est cachee par sa redefinition dans la 
classe Tour (voir figure 8). La notation qualifiee permet l'acces 
a la methode de la classe de base, dans le contexte de l'objet 
receveur. Elle ne peut etre utilisee que dans cette situation. 

Une fois la classe Tour definie, on peut en declarer des 
instances et invoquer des methodes : 

t : Tour; 



t.Empiler (10); 
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t.Depiler; 
t.Empiler (20); 

t.Empiler (5); -- impossible d'empiler 

Comme on l'a dit, les methodes de la classe de base restent 
accessibles. Dans cet exemple, t.Depiler invoque Pile.Depiler. 

Enrichissement par heritage 

Nous allons maintenant definir une classe derivee de la classe 
Tour en ajoutant la possibilite de representer graphiquement la 
tour. Pour cela nous supposons l'existence des classes Fenetre et 
Rectangle, avec les definitions partielles suivantes : 

Fenetre = classe { 
methodes 

procedure Effacer (); 

} 

Rectangle = classe { 
methodes 

procedure Centre (posX, posY : entier); 
procedure Taille (largeur, hauteur : entier); 
procedure Dessiner (f : Fenetre); 

} 

TourG est une sous-classe de Tour definie comme suit : 

TourG = classe Tour { 
champs 

f : Fenetre; 

x, y : entier; 
methodes 

procedure Placer (posX, posY : entier); 

procedure Dessiner (); 

procedure Empiler (valeur: entier); 

procedure Depiler (); 

} 
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II s'agit ici d'un enrichissement : trois nouveaux champs 
indiquent la fenetre de l'ecran dans laquelle sera affichee la 
tour, et la position de la tour dans cette fenetre. Chaque etage de 
la tour sera represente par un rectangle de taille proportionnelle 
a la valeur entiere qui le represente dans la tour. Deux nouvelles 
methodes permettent d'affecter une position a la tour et de 
dessiner la tour. Enfin, les methodes Empiler et Depiler sont 
redefinies afin d'assurer que la tour est redessinee a chaque 
modification. Le corps des methodes est decrit ci-dessous. 

Placer affecte la position de la tour et la redessine. 

procedure TourG. Placer (posX, posY : entier) { 
x := posX; 
y := posY; 
Dessiner (); 

} 

Dessiner commence par effacer la fenetre, puis redessine la 
tour etage jjar etage. Dessiner est similaire dans son principe a la 
methode Ecrire definie auparavant dans la classe Pile. 

procedure TourG. Dessiner () { 
rect : Rectangle; 
f. Effacer (); 

pour i := 1 a sommet faire { 
rect.Centre (x, y - i); 
rect.Taille (pile [i], 1); 
rect. Dessiner (f); 

} 

} 

Empiler et Depiler invoquent la methode de meme nom dans 
la classe de base Tour et redessinent la tour. On pourrait bien sur 
optimiser l'affichage, mais ce n'est pas l'objet de l'exemple. 

procedure TourG. Empiler (valeur: entier) { 
Tour. Empiler (valeur); 
Dessiner (); 

} 



48 Les langages a objets 



procedure TourG. Depiler () { 
Tour.Depiler (); 
Dessiner (); 

} 

II est a noter que Tour.Depiler n'a pas ete definie. En fait la 
classe Tour herite Depiler de la classe Pile, done Tour.Depiler est 
identique a Pile. Depiler . Neanmoins, il serait imprudent 
d'utiliser Pile. Depiler directement car on peut etre amene a 
redefinir Depiler dans Tour. 

3.3 HERITAGE MULTIPLE 

L'heritage multiple permet d'utiliser plusieurs classes de base. 
La classe TourG, par exemple, represente une tour qui sait 
s'afficher dans une fenetre. En changeant legerement de point 
de vue, on peut considerer que la classe TourG est a la fois une 
tour et une fenetre. On a alors un heritage multiple de Tour et 
de Fenetre (figure 9). Voyons la definition de la classe TourGM 
ainsi obtenue : 

TourGM = classe Tour, Fenetre { 
champs 

x, y : entier; 
methodes 

procedure Placer (posX, posY : entier); 
procedure Dessiner (); 
procedure Empiler (valeur: entier); 
procedure Depiler (); 

} 

L'heritage multiple est mentionne en faisant apparaitre la liste 
des classes de base dans l'en-tete de la declaration. Le champ/ 
n'apparait plus : il est remplace par l'heritage de Fenetre. 

La seule methode qui change par rapport a la classe TourG est 
la methode Dessiner : 
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V J 




\ J 

Figure 9 - Heritage multiple de la classe TourGM 

procedure TourGM. Dessiner () { 
rect : Rectangle; 
Effacer (); 

pour i := 1 a sommet faire { 
rect.Centre (x, y - i); 
rect.Taille (pile [i], 1); 
rect.Dessiner (moi); 

} 

} 

On constate que l'invocation de la methode Effacer n'est plus 
qualifiee par le champ /. En effet, cette methode est maintenant 
heritee de la classe Fenetre. Par ailleurs, l'invocation de la 
methode Dessiner prend comme argument la pseudo-variable 
moi. En effet, TourGM herite maintenant de Fenetre, done une 
TourGM est une fenetre : on utilise ici le polymorphisme 
d'heritage sur le parametre de la methode Dessiner. 

Bien que les differences entre les implementations de TourG et 
TourGM soient minimes, l'effet de l'heritage multiple est plus 
important qu'il n'y parait. En effet, alors que TourG n'herite 
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que des methodes de Tour, TourGM herite de celles de Tour et 
de Fenetre. II est done tout a fait possible d'ecrire : 

tgm : TourGM; 

tgm. Placer (100, 100); 
tgm.Empiler (20); 
tgm.Empiler (10); 
tgm. Ef facer (); 

L'invocation d'Effacer est correcte puisque Effacer est heritee 
de Fenetre. Pour un objet de la classe TourG, cet envoi de 
message aurait ete illicite. On voit done que le choix 
d'implementer une tour graphique par la classe TourG ou la 
classe TourGM depend du contexte d'utilisation dans 
l'application. L'heritage, comme l'heritage multiple, ne doit pas 
etre utilise comme une facilite d'implementation, mais comme 
une facon de specifier des liens privilegies entre classes. 

L'heritage multiple cree cependant une ambiguite : supposons 
que la classe Fenetre definisse une methode Ecrire, qui imprime 
son etat. La classe Tour de son cote herite une methode Ecrire 
de la classe Pile. Que se passe-t-il si l'on ecrit : 

tgm. Ecrire (fich); 

II y a un conflit car la classe TourGM herite deux fois de la 
methode Ecrire. Les langages resolvent ce probleme de 
differentes manieres : 

• l'ordre de l'heritage multiple determine une priorite entre 
les classes ; dans notre cas TourGM herite d'abord de Tour, 
puis de Fenetre, done Tour .Ecrire masque Fenetre. Ecrire. 
Le resultat est done d'imprimer la tour, e'est-a-dire la pile. 

• il faut qualifier l'invocation de la methode, par exemple 
tgm. Fenetre. Ecrire (fich). Cela suppose done que 
l'utilisateur connaisse le graphe d'heritage, ce qui ne 
favorise pas l'idee d'encapsulation et d' abstraction. C'est le 
mecanisme choisi par Modula3 et C++. 

• il faut renommer, lors de l'heritage, les methodes qui 
engendrent des conflits. On peut ainsi heriter de Tour, et de 
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Fenetre en renommant la methode Ecrire heritee de fenetre 
en EcrireF. tgm.Ecrire(fich) imprime done la tour, alors que 
tgm.EcrireF(fich) imprime la fenetre. C'est le mecanisme 
impose par Eiffel, et disponible en C++. 

• il faut definir une methode Ecrire dans la classe TourGM, 
qui levera le conflit en masquant les deux methodes Ecrire. 

La derniere methode est toujours realisable. Dans notre 
exemple, on pourrait definir cette methode de la facon suivante : 

procedure TourGM. Ecrire (sortie : Fichier) { 
Tour. Ecrire (sortie); 
Fenetre. Ecrire (sortie); 
sortie. Ecrire (x); 
sortie. Ecrire (y); 

} 

Cette methode ecrit la partie Tour, la partie Fenetre et les 
champs propres de TourGM. Les invocations qualifiees 
Tour. Ecrire et Fenetre. Ecrire levent l'ambiguite en meme temps 
qu'elles evitent l'appel recursif de TourGM. Ecrire. 

Lorsque des champs de plusieurs classes de base portent le 
meme nom, les memes problemes de conflits d'acces se posent. 
lis sont resolus par un acces qualifie (en C++) ou par 
renommage (en Eiffel). 

Nous avons evoque au chapitre precedent d'autres problemes 
concernant l'heritage multiple, et notamment l'heritage repete : 
que se passe-t-il si une classe herite, directement ou 
indirectement, plusieurs fois de la meme classe ? Faut-il 
dupliquer les champs de cette classe ou doivent-ils apparaitre 
une seule fois ? 

En C++, la notion de classe de base virtuelle permet de ne voir 
qu'une fois une classe de base qui est accessible par plusieurs 
chemins d'heritage. En Eiffel, le controle est plus fin car chaque 
champ d'une classe de base heritee plusieurs fois peut etre 
duplique ou partage, selon que le champ est renomme ou non. 
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3.4 LIAISON DYNAMIQUE 

Tel que nous l'avons presente, l'heritage des methodes dans 
un langage a objets type permet de determiner de facon statique 
les invocations de methodes : pour un objet o de la classe A, 
l'appel 

o.m (parametres) 

est resolu en recherchant dans la classe A une methode de nom 
m. Si elle n'est pas trouvee, la recherche se poursuit dans la 
classe de base de A, et ainsi de suite jusqu'a trouver la methode 
ou atteindre la racine de l'arbre d'heritage. Si la methode est 
trouvee, l'invocation de methode est correcte, sinon elle est 
erronee. 

Le compilateur peut profiter de cette recherche, destinee a 
verifier la validite du programme, pour engendrer le code qui 
appelle directement la methode trouvee. Cela evite une 
recherche similaire a 1' execution et rend done le programme 
plus efficace. Cela s'appelle la liaison statique. 

Malheureusement, le polymorphisme d'heritage rend cette 
optimisation invalide, comme le montre l'exemple suivant : 

t : Tour ; 
tg : TourG ; 

t := tg ; 

t.Empiler (10) ; -- que se passe-t-il ? 

L' affectation de la tour graphique tg a la tour simple t est 
correcte en vertu du polymorphisme d'heritage : une tour 
graphique est un cas particulier de tour, done un objet de type 
tour peut referencer une tour graphique. En utilisant la liaison 
statique, le compilateur resout l'invocation d' Empiler par 
l'appel de Tour. Empiler, car t est declare de type Tour. Mais t 
contient en realite, lors de l'execution, un objet de classe TourG, 
et l'invocation de Tour .Empiler est invalide : il aurait fallu 
invoquer TourG. Empiler. 
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Dans cet exemple, le typage statique ne nous permet pas de 
savoir que t contient en realite un objet d'une sous-classe de 
Tour et la liaison statique brise la semantique du polymorphisme 
d'heritage. 

Les methodes virtuelles 

Ce probleme avait ete note des Simula, et resolu en 
introduisant la notion de methode virtuelle : en declarant 
Empiler virtuelle, on indique d'utiliser une liaison dynamique et 
non plus une liaison statique : le controle de type a toujours lieu 
a la compilation, mais la determination de la methode a appeler 
a lieu a l'execution, en fonction du type effectif de l'objet. On 
comprend aisement que la liaison dynamique est plus chere a 
l'execution que la liaison statique, mais qu'elle est indispensable 
si Ton veut garder la semantique du polymorphisme d'heritage. 

L'exemple suivant montre une autre situation dans laquelle les 
methodes virtuelles sont indispensables : 

tg : TourG ; 
tg. Initialiser (4); 

On initialise une tour graphique avec quatre disques. Nous 
allons voir que la encore, il faut que Empiler ait ete declaree 
virtuelle. La procedure Initialiser est heritee de Tour. Voici 
comment nous l'avons definie : 

procedure Tour. Initialiser (n : entier) { 
pour i := n a 1 faire Empiler (i); 

} 

Si Empiler n'est pas declaree virtuelle, son invocation est 
resolue par liaison statique par l'appel de Tour .Empiler , puisque 
le receveur est considere de classe Tour. Lorsque Ton invoque 
tg.Initialiser(4), le receveur sera en realite de classe TourG, et 
c'est la mauvaise version d'Empiler qui sera invoquee (voir 
figure 10). En declarant Empiler virtuelle, ce probleme disparait. 
En l'occurrence, c'est TourG. Empiler qui sera invoquee, 
provoquant le dessin de la tour au fur et a mesure de son 
initialisation. 
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Figure 10 - Liaison statique contre liaison dynamique 



L'utilisation extensive du polymorphisme dans les langages a 
objets pourrait laisser penser que toutes les methodes doivent 
etre virtuelles. C'est la solution choisie dans Eiffel et Modula3, 
qui assurent au programmeur que tout se passe comme si la 
liaison etait toujours dynamique. 

Par contre, C++ et Simula obligent a declarer explicitement les 
methodes virtuelles comme telles. Cela offre au programmeur la 
possibilite de choisir entre la securite de la liaison dynamique et 
l'efficacite de la liaison statique, a ses risques et perils. En 
pratique, on se rend compte qu'un nombre limite de methodes 
ont effectivement besoin d'etre virtuelles, mais qu'il est difficile 
de determiner lesquelles, surtout lorsque les classes sont 
destinees a etre reutilisees. 

L 'implementation de la liaison dynamique 

L' implementation usuelle de la liaison dynamique consiste a 
attribuer a chaque methode virtuelle un indice unique pour la 



une Pile 



une autre Pile 
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Code de Pile.Empiler 
Code de Pile.Depiler 



Code de Tour.Empiler 



une Tour 

Figure 11 - Implementation de la liaison dynamique 



hierarchie de classes a laquelle elle appartient. Lors de 
l'execution, chaque classe est representee par une table, qui 
contient pour un indice donne l'adresse de la methode 
correspondante de cette classe. Chaque objet d'une classe 
contenant des methodes virtuelles contient l'adresse de cette 
table (figure 11). L'invocation d'une methode exige 
simplement une indirection dans cette table. Le cout de 
1' implementation est done le suivant : 

• une table, dite table virtuelle, par classe ; 

• un pointeur vers la table virtuelle par objet ; 

• une indirection par invocation de methode virtuelle. 



On peut considerer ce cout comme acceptable, surtout si on le 
compare au cout d' invocation des methodes dans les langages 
non types (decrit a la fin de la section 4.3 du chapitre 4). On 
peut aussi considerer qu'il est inutile de supporter ce cout 
systematiquement, et e'est la raison pour laquelle Simula et C++ 
donnent le choix (et la responsabilite) au programmeur de 



56 Les langages a objets 



declarer virtuelles les methodes qu'il juge utile. Modula3, au 
contraire, tire parti de la table virtuelle necessaire a chaque objet 
pour autoriser un objet a redefinir des methodes : il suffit de lui 
creer une table virtuelle propre. On quitte alors le modele strict 
des langages de classes, puisque ce n'est plus la classe qui 
detient le comportement de toutes ses instances. 

3.5 REGLES DE VISIBILITE 

La declaration explicite des types dans un langage assure la 
detection d'erreurs des la compilation, et permet done au 
programmeur de se proteger contre lui-meme. Un autre aspect 
de cette protection concerne les regies de visibilite, e'est-a-dire 
les mecanismes d'encapsulation qui permettent de limiter 
Faeces a des donnees et methodes. Le role principal de 
l'encapsulation est de masquer les details d'implementation 
d'une classe afin d'eviter que des clients exterieurs puissent la 
modifier impunement. On peut alors modifier a posteriori les 
parties cachees sans effet perceptible pour les clients. 

Nous avons considere jusqu'a present que les regies de 
visibilite etaient les suivantes : 

• Les champs d'une classe sont visibles seulement dans le 
corps des methodes de cette classe et de ses classes derivees. 

• Les methodes d'une classe sont visibles de l'exterieur par 
tout client. 

L'unite de l'encapsulation : classe ou objet 

La premiere regie ci-dessus est ambigue : soit une classe A et 
une methode m de cette classe ; on peut comprendre la regie de 
deux facons : 

• dans le corps de m, on a acces aux champs de n'importe 
quel objet de classe A (en particulier le receveur de m) ; 

• dans le corps de m, on n'a acces qu'aux champs de son 
receveur. Par exemple, si m a un parametre de classe A, m 
n'a pas acces aux champs de ce parametre. 
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Cette deuxieme interpretation est plus restrictive. Elle 
correspond a un domaine de visibilite qui est l'objet : un objet 
n'est connu que des methodes de sa classe, une methode ne 
connait que les champs de son receveur. La premiere 
interpretation correspond a un domaine de visibilite qui est la 
classe tout entiere : une classe connait ses instances, done toute 
methode de cette classe connait toute instance de cette classe. 
Cette interpretation est celle utilisee dans les langages de la 
famille Simula. A l'inverse, les langages de la famille Smalltalk 
adoptent generalement la premiere interpretation, et considerent 
done l'objet comme l'unite de l'encapsulation. 

Une fois definie cette notion de domaine de visibilite, il reste a 
montrer les differents mecanismes offerts par les langages. 
Modula3, C++ et Eiffel presentent de ce point de vue des 
approches differentes. 

Modula3 : visible ou cache 

Par defaut, tous les champs et methodes d'une classe Modula3 
sont visibles de n'importe quel client. Neanmoins, un 
mecanisme permet de creer un type opaque identique a une 
classe donnee, dont on ne rend visible que les methodes 
souhaitees. Ce mecanisme, assez lourd, oblige a creer au moins 
deux types par classe : un type ouvert contenant les champs et 
methodes, et un type ferme, utilise par les clients, ne presentant 
que les methodes utiles. 

D'un autre cote, cette technique permet de definir plusieurs 
interfaces a une classe donnee en definissant plusieurs types 
limitant l'acces a cette classe de differentes manieres. Ainsi on 
peut imaginer qu'une classe derivee souhaite un acces plus large 
a sa classe de base qu'une classe quelconque. 

C++ : prive, protege ou public 

En C++, les mecanismes de visibilite s'appliquent 
indifferemment aux champs et aux methodes, que nous 
appellerons collectivement des membres dans cette section, 
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conformement a la terminologie C++. Le type de visibilite offert 
par C++ est intermediate entre ceux de Modula3 et Eiffel. Un 
membre d'une classe peut etre declare avec l'un des trois 
niveaux de visibilite 1 suivants : prive, protege, public. 

• Un membre prive n'est visible que depuis les methodes de 
la classe dans laquelle il est defini. Aucune classe exterieure 
n'y a acces, pas meme une classe derivee. 

• Un membre public est au contraire accessible a tout client. 

• Enfin, un membre protege n'est accessible qu'aux 
methodes de la classe et de ses classes derivees. Cela enterine 
le fait qu'une classe derivee est un client privilegie de sa 
classe de base. 

Ces niveaux de visibilite sont transmis par heritage : un 
membre public d'une classe A est public dans toute classe 
derivee de A. De meme, un membre protege dans A est protege 
dans toute classe derivee de A. En revanche, un membre prive 
n'est pas visible dans une classe heritee. 

C++ offre trois mecanismes complementaires en ce qui 
concerne la visibilite : 

• Vheritage prive permet de construire une classe B derivee 
d'une classe A sans que ce lien d'heritage ne soit visible de 
l'exterieur : les membres herites de A sont prives dans B, et 
il n'y a pas de polymorphisme d'inclusion entre B et A. 

• une classe peut reexporter un membre herite avec un niveau 
de visibilite different. Par exemple, la methode protegee m 
d'une classe A peut etre rendue publique dans une classe B 
derivee de A. Dans le cas de l'heritage prive, on peut ainsi 
rendre visibles certains membres de la classe de base. 

• une classe peut avoir des classes amies et des methodes 
amies : une classe B amie de A ou une methode / amie de A 
a acces a tous les membres de la classe A. Cela permet 



1 En C++, on parle d'accessibilite plutot que de visibilite. Bien que la 
difference soit significative, nous n'entrerons pas dans les details ici. 
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d'ouvrir une classe a des clients privilegies, sans toutefois 
autoriser l'acces a une classe sans son consentement. En 
effet, c'est la classe A qui doit declarer que B et / sont amies. 

Eiffel : exportation explicite 

Le mecanisme le plus raffine pour ce qui concerne les regies 
de visibilite est celui d'Eiffel : chaque classe decrit la liste des 
membres qu'elle exporte. Chaque membre ainsi exporte peut 
etre qualifie par une liste de classes clientes. Par defaut, un 
membre exporte est visible par n'importe quel client. Si Ton 
qualifie le membre avec une liste de classes, alors ce membre 
n'est visible que par ces classes et leurs classes derivees. 

Le controle de la visibilite des membres herites est realise par 
le meme mecanisme. On peut retransmettre les membres herites 
avec la visibilite declaree dans la classe de base, ou bien changer 
leur visibilite. 

Des progres a faire 

Diverses raisons d'ordre syntaxique peuvent faire preferer tel 
ou tel mecanisme de visibilite. Dans tous les cas, il n'est pas 
facile de maitriser la combinaison entre la visibilite, l'heritage et 
le polymorphisme. 

La diversite syntaxique cache un reel probleme semantique : 
on ne maitrise pas aujourd'hui les notions de visibilite de facon 
satisfaisante, et c'est la raison pour laquelle il n'existe pas de 
mecanisme simple qui reponde a des besoins par ailleurs mal 
definis : la visibilite doit etre compatible avec l'heritage, mais 
des classes sans relation d'heritage doivent pouvoir se connaitre 
de facon privilegiee, comme les amis de C++. Des lors, un 
mecanisme global est necessaire mais pas suffisant. Des travaux 
sur la notion de vue, assez proche du mecanisme de Modula3, 
sont prometteurs : ils permettent de definir plusieurs vues d'une 
classe donnee, c'est-a-dire plusieurs interfaces. Un client choisit 
alors la vue qui l'interesse. Cet aspect des langages a objets n'est 
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done pas fige, et Ton peut s'attendre a de nouvelles solutions a 
court terme. 

3.6 MECANISMES SPECIFIQUES 
Initialisation des objets 

L'un des problemes classiques dans les langages qui 
manipulent des variables (et, dans notre cas, des objets) est celui 
de 1' initialisation. Ainsi, en Pascal, une variable non initialisee ne 
sera pas reperee par le compilateur et pourra provoquer un 
comportement aleatoire du programme. Meme lorsque les 
variables non initialisees sont reperees par le compilateur, le 
programmeur doit les initialiser explicitement, ce qui alourdit le 
programme. La notion d'objet offre un terrain favorable pour 
assurer l'initialisation des objets. En effet, on peut imaginer 
qu'une methode particuliere prenne en charge automati- 
quement l'initialisation de tout nouvel objet. C++ et Eiffel 
offrent de tels mecanismes. 

Une classe Eiffel peut declarer une methode speciale, de nom 
predefini Create, qui assure l'initialisation des objets de cette 
classe. Le programmeur doit invoquer explicitement cette 
methode, qui a un statut particulier. Ainsi, l'instruction o.Create 
invoque en realite les methodes Create de la classe de o et de 
chacune de ses classes de base. Cela assure que tous les 
composants de o sont initialises correctement. II s'ensuit que la 
methode Create ne s'herite pas ; le compilateur engendre au 
contraire une methode Create pour les classes qui n'en 
definissent pas. Cette methode initialise chacun des champs a 
une valeur par defaut dependant de son type. 

En C++, une classe peut declarer des constructeurs, methodes 
speciales qui portent le nom de la classe elle-meme. Divers 
constructeurs, avec des listes de parametres differentes, 
permettent de definir plusieurs moyens d'initialisation. Un 
constructeur sans parametre est un constructeur par defaut. 
L'appel du constructeur est realise automatiquement, par le 
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compilateur, a chaque declaration d'objet. Comme en Eiffel, le 
constructeur d'une classe derivee appelle automatiquement celui 
de sa classe de base. Par contre, a l'inverse d'Eiffel, l'appel du 
constructeur est implicite, ce qui evite les oublis malencontreux. 
De facon symetrique a l'initialisation, C++ permet la definition 
de methodes specifiques pour la destruction des objets : ces 
destructeurs sont, comme les constructeurs, invoques automati- 
quement lorsqu'un objet devient inaccessible. Ainsi un objet 
declare comme variable locale d'une methode voit son 
destructeur appele lorsque la methode termine son execution. 

La destruction assuree des objets est aussi importante que leur 
initialisation. Par exemple, si Ton considere un objet 
representant un fichier, le destructeur peut assurer la fermeture 
du fichier lorsque celui n'est plus accessible. Le plus souvent, 
les destructeurs sont utilises pour detruire des structures 
dynamiques contenues dans les objets. Ainsi, une classe Liste, 
contenant une liste chainee d'objets alloues dynamiquement, 
peut assurer la destruction de ses elements dans son destructeur. 

Voici comment Ton pourrait definir et utiliser un constructeur 
et un destructeur pour la classe Tour. Nous avons pour cela 
etendu la syntaxe de notre langage par l'ajout des mots cles 
constructeur et destructeur. 

Tour = classe Pile { 

methodes 

constructeur Tour (taille : entier); 
destructeur Tour (); 

} 

constructeur Tour (taille : entier) { 
Initialiser (taille); 

} 

destructeur Tour () { 

tantque sommet > 0 faire Depiler (); 

} 
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{ - exemple d'utilisation 

t : Tour (10); -- constructeur Tour (entier) 

} -- appel du destructeur de t 
Genericite 

Tout au long de ce chapitre, nous avons utilise la classe Pile 
pour representer une pile d'entiers. Si Ton voulait gerer une 
pile d'autres objets, il faudrait definir une nouvelle classe, 
probablement tres proche dans sa definition et son imple- 
mentation de la classe Pile. La genericite, qui met en oeuvre le 
polymorphisme parametrique, est un mecanisme attrayant pour 
definir des types generaux. Par exemple, toute classe contenant 
une collection d'objets est un bon candidat pour une classe 
generique : tableau, liste, arbre, etc. En effet de telles classes 
conteneurs dependent peu de la classe des objets contenus. 

La genericite nous permet de definir une classe generique 
GPile, parametree par le type de ses elements : 

GPile = classe (T : classe) { 
champs 

pile : tableau [1..N] de T; 
sommet : entier; 
methodes 

procedure Empiler (val : T); 
procedure Depiler (); 
fonction Sommet () : T; 

} 

Pile = classe GPile (entier); -- instanciation 
p : Pile; 

p. Empiler (10); 

On ne peut utiliser la classe GPile telle quelle : il faut 
l'instancier en lui donnant le type de ses elements. En revanche, 
on peut deriver GPile ; la classe derivee est elle aussi generique. 

La genericite et l'heritage sont deux mecanismes qui 
permettent de definir des families potentiellement infinies de 
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classes. Aucun n'est reductible a l'autre, et un langage a objets 
qui offre la genericite est strictement plus puissant qu'un 
langage qui ne l'offre pas. Eiffel permet la definition de classes 
generiques. La genericite est egalement definie pour C++, mais 
elle n'est pas implementee dans les compilateurs actuels. 

Gestion dynamique des objets 

Nous avons introduit la notion d'objet dans ce chapitre en 
generalisant la notion d'enregistrement presente dans des 
langages tels que Pascal. En Pascal comme dans d'autres 
langages, on peut declarer des objets qui ont une duree de vie 
delimitee par leur portee (variables locales), mais on peut aussi 
gerer des variables dynamiques par l'intermediaire des 
pointeurs. L'utilisation de variables dynamiques laisse au 
programmeur la charge de detruire les variables inutilisees, a 
moins que le module d'execution du langage n'offre un 
ramasse-miettes qui detruise automatiquement les variables 
devenues inaccessibles. 

En C++, les objets sont implemented par des enregistrements, 
et le programmeur peut utiliser des objets automatiques ou des 
pointeurs vers des objets dynamiques. Dans ce cas, 1' allocation 
dynamique et la liberation de la memoire pour les objets 
devenus inutiles ou inaccessibles est a sa charge. Les notions de 
constructeurs et de destructeurs aident cette gestion sans la 
rendre totalement transparente. A 1' inverse, Modula3 et Eiffel 
assurent eux-memes la gestion dynamique de la memoire. Un 
objet est en realite un pointeur vers l'enregistrement de ses 
champs. Cette implementation facilite le travail du 
programmeur, qui n'a pas a se soucier de la destruction des 
objets : un algorithme de ramasse-miettes s'en occupe pour lui a 
l'execution. Le choix d'implementer les objets par des 
pointeurs, et non par des enregistrements comme en C++, offre 
l'avantage de la simplicite. En revanche, l'acces a tout champ 
d'un objet necessite une indirection lors de l'execution, ce qui 
peut etre couteux. De plus, les algorithmes de ramasse-miettes 
aujourd'hui disponibles sont generalement peu efficaces, et 
coutent cher en temps et en espace memoire lors de l'execution. 
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Bien entendu, ce probleme n'est pas propre aux langages a 
objets. Neanmoins, on pourrait esperer que le choix du langage 
n'implique pas le choix de la gestion des objets a l'execution. 
C'est le cas dans Modula3, ou Ton peut indiquer pour chaque 
classe si Ton souhaite une gestion automatique par ramasse- 
miettes, ou bien une gestion a la charge du programmeur. C++ 
permet egalement au programmeur de redefinir la gestion des 
objets dynamiques au niveau de chaque classe. On peut ainsi 
utiliser les proprietes specifiques d'une classe pour gerer la 
memoire plus efficacement qu'avec un ramasse-miettes general. 

3.7 CONCLUSION 

La richesse des langages a objets types est encore loin d'etre 
epuisee. Les langages actuels souffrent encore du lourd heritage 
des langages structures. De nombreux travaux de recherche 
concernent la semantique des systemes de types mis en oeuvre 
dans ces langages, et decouvrent la complexite des problemes 
mis en jeu des lors que Ton veut combiner heritage multiple, 
genericite, surcharge, etc. Les langages actuels ont deja fait la 
preuve de leurs qualites : securite pour le programmeur, facilite 
de maintenance, reutilisation des classes, efficacite du code 
executable. lis sont de plus en plus facilement adoptes dans les 
entreprises pour le developpement de logiciels complexes : 
systemes d'exploitation, environnements de programmation, 
interfaces graphiques, simulation, etc. 



Chapitre 4 



SMALLTALK 
ET SES DERIVES 



Nous allons presenter dans ce chapitre le langage Smalltalk et 
les langages qui en sont derives. lis presentent la caracteristique 
commune d'etre des langages non types et interpreted ou semi- 
compiles. 

La premiere version de Smalltalk date de 1972 et fut inspiree 
par les concepts de Simula et les idees d'Alan Kay, au 
laboratoire PARC de Xerox. Apres une dizaine d'annees 
d'efforts et plusieurs versions intermediaires, notamment 
Smalltalk-72 et Smalltalk-76, Smalltalk-80 represente la version 
la plus repandue du langage et de la bibliotheque de classes qui 
l'accompagne. Smalltalk-80 inclut egalement un systeme 
d'exploitation et un environnement de programmation 
graphique. Xerox a aussi cree des machines specialisees pour 
Smalltalk : le Star et le Dorado. Aujourd'hui, Smalltalk est 
disponible sur stations de travail Unix, sur Apple Macintosh, et 
sur compatibles IBM PC. 
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La syntaxe employee dans ce chapitre pour presenter les 
exemples est proche de celle de Smalltalk. Les commentaires 
sont introduits par deux tirets et se poursuivent jusqu'a la fin de 
la ligne. Toute instruction est un envoi de message, qui a l'une 
des formes suivantes : 

receveur msgl 

receveur msg2 argument 

receveur del : arg1 cle2: arg2 ... clen: argn 

La premiere forme est un envoi de message unaire (message 
sans argument), par exemple : 

3 factorielle -- calculer 3! 

Tableau Nouveau -- creer un nouveau tableau 

La deuxieme forme est un envoi de message binaire (message 
avec un argument). Les expressions arithmetiques et 
relationnelles sont exprimees avec des messages binaires : 

3 + 4 - receveur = 3, msg = +, argument = 4 
a < b -- receveur = a, msg = <, argument = b 

Enfin la troisieme forme est utilisee pour des messages n-aires 
(a un ou plusieurs arguments) et est appelee message a mots 
cles. Chaque mot cle se termine par le symbole « : » et 
correspond a un argument : 

tab en: 3 mettre: a 

Ici le receveur est tab, le message est en :mettre: et les 
arguments sont 3 et a. Le nom du message est la concatenation 
des mots cles (y compris les deux-points). Les noms de message 
peuvent etre prefixes les uns des autres. Dans ce cas, on prend la 
plus longue serie de mots cles. Les parentheses permettent de 
lever les ambigui'tes ou de forcer l'ordre d'evaluation. A titre 
d'exemple, nous utiliserons les messages en: et en:mettre:, pour 
l'acces aux elements de tableau : 



tab en: 3 

tab en: 4 mettre: a 

tab en: (tab en: 5) mettre: a 



tab [3] 
tab [4] := a 
tab [tab [5]] := a 
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La premiere expression retourne l'element du tableau tab a 
l'indice 3. La deuxieme affecte a a l'element d'indice 4. La 
derniere expression affecte a a tab [tab [5]]. Dans la realite, en: 
et emmettre: ne sont pas dedies ni reserves a l'acces aux 
tableaux, ceux-ci n'etant pas un type predefini de Smalltalk. 

Les deux autres symboles utilises dans notre langage sont le 
symbole d' affectation « «- » et le symbole de retour de valeur 
« t ». Nous aurons egalement besoin de blocs qui seront decrits 
dans la section suivante. 

Bien que Smalltalk permette de definir des classes et des 
methodes par envoi de messages, nous utiliserons une forme 
plus lisible qui s'apparente a celle offerte par l'environnement 
graphique de programmation Smalltalk. La declaration d'une 
classe aura la forme suivante : 

classe idClasse 
superclasse idClasse 
champs id1 id2 ... idn 

methodes 

suite de declarations de methodes 

L'ajout de methodes dans une classe existante aura une forme 
identique, en omettant les lignes superclasse et methodes. 

Une declaration de methode se presente comme suit : 

del : arg1 cle2: arg2 ... clen: argn 
I idvaii idvar2 . . . idvarn I 
corps de la methode 

La premiere ligne est le profil de la methode. Ici, il s'agit 
d'une methode a mots cles. La deuxieme ligne est optionnelle et 
permet de declarer des variables locales. Enfin le corps de la 
methode est une suite d'expressions Smalltalk, separees par des 
points. 
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4.1 TOUT EST OBJET 

Les concepts de base de Smalltalk peuvent se decrire en quatre 
axiomes : 

1 . Toute entite est un objet. 

2. Tout objet est l'instance d'une classe. 

3. Toute classe est sous-classe d'une autre classe. 

4. Tout objet est active a la reception d'un message. 

L'axiome 2 definit la notion d'instanciation. L'axiome 3 
definit la notion ^heritage. Bien distinguer ces deux types de 
liens (lien d'instanciation est-instance-de et lien d'heritage est- 
sous-classe-de) est fondamental a la comprehension de 
Smalltalk. II decoule des axiomes 1 et 2 que toute classe est une 
entite du systeme, done un objet. En tant qu'objet, toute classe 
est done l'instance d'une classe, que Ton appelle sa metaclasse. 
Cette notion de metaclasse est fondamentale dans Smalltalk, et 
nous y reviendrons plus loin en detail. 

Les seules entites predefinies dans le langage sont : 

• les nombres entiers, definis dans la classe Entier ; 

• la classe Objet qui est la seule a ne pas respecter le troisieme 
axiome {Objet n'est la sous-classe d'aucune classe) ; 

• la classe Bloc detaillee ci-dessous ; 

• la metaclasse Classe. 

La seule structure de controle est l'envoi de message aux 
objets. En particulier, le langage ne contient aucune structure de 
controle telles que conditionnelle, boucles, etc. Celles-ci sont 
definies grace a la notion de bloc. Un bloc est une instance de la 
classe predefinie Bloc. Un bloc contient une liste optionnelle de 
parametres et un ensemble d'expressions Smalltalk executables, 
separees par des points. L'evaluation d'un bloc est obtenue en 
lui envoyant le message unaire valeur. Les blocs sont notes entre 
crochets : 
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incr «- [ n «- n + 1 ]. 

incr valeur. -- ajoute 1 a n 

On peut comparer les blocs a des procedures anonymes que 
Ton peut executer par l'envoi du message valeur, ou a des 
lambda-expressions de Lisp. Les blocs peuvent avoir des 
parametres. Dans ce cas, le bloc commence par la liste des noms 
des parametres, prefixes d'un deux-points, et cette liste est 
separee du corps du bloc par une barre verticale. Le message 
valeur: prend comme argument la valeur du parametre reel. 
Nous utiliserons seulement des blocs avec un parametre : 

ajouter «- [ :x I n «- n + x ]. -- parametre = x 

ajouter valeur: 10. -- ajouter 10 a n 

Le langage est done reduit au strict minimum. De ce point de 
vue, on peut comparer Smalltalk au langage Lisp. Comme Lisp, 
Smalltalk est fourni avec un environnement qui evite au 
programmeur de tout reconstruire dans chaque programme. Cet 
environnement est un ensemble de classes d'interet general 
telles que booleens, tableaux, chaines de caracteres, etc. II 
contient egalement les classes de l'environnement de 
programmation Smalltalk, qui permettent notamment de 
construire des applications graphiques interactives. 

4.2 CLASSES, INSTANCES, MESSAGES 

Le deuxieme axiome indique que tout objet est l'instance 
d'une classe. Precisons ce que sont les objets et les classes : un 
objet contient un etat, stocke dans un ensemble de champs 
(appeles en Smalltalk variables d'instance). Ces champs sont 
strictement prives et accessibles seulement par l'objet. Un objet 
ne peut etre manipule qu'a travers les messages qu'on lui 
envoie. Chaque objet repond a un message en activant une 
methode (axiome 4). Les methodes ne sont pas stockees dans 
l'objet lui-meme, mais dans sa classe. Le lien d'instanciation qui 
unit l'objet a sa classe est done crucial : il lui permet de 
retrouver la methode a activer a la reception d'un message. 
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Figure 12 - Instanciation d'un objet Smalltalk 

Les methodes sont stockees dans la classe avec leurs corps, 
dans le dictionnaire des methodes. Une classe contient 
egalement la liste des noms des champs de ses instances. Cela lui 
permet de creer de nouvelles instances : une classe est un objet 
generateur. La creation d'un objet, ou instanciation, est realisee 
en envoyant le message Nouveau a une classe. La classe, en tant 
qu'objet, repond au message Nouveau en creant un nouvel objet 
(figure 12). L'instanciation, si elle est une operation primitive 
du langage, est neanmoins realisee par le seul moyen de 
controle qu'est l'envoi de message. 

Pour resumer les points precedents : 

• un objet contient un ensemble de champs ; 

• une classe contient la description des champs de ses 
instances et le dictionnaire des methodes que peuvent 
executer ses instances ; 

• un objet est cree par l'envoi du message Nouveau a sa 



La correspondance entre un message recu par un objet et la 
methode a activer se fait simplement sur le nom du message : 
l'objet recherche dans le dictionnaire des methodes de sa classe 
une methode portant le meme nom que le message. Si une telle 
methode existe, elle est executee dans le contexte de l'objet 
receveur. Le corps de la methode peut done acceder aux 
champs de l'objet qui, rappelons-le, lui sont prives. 



classe. 
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La reception d'un message qui n'a pas de methode 
correspondante dans le dictionnaire des methodes de sa classe 
provoque une erreur. L'erreur se manifeste par l'envoi d'un 
message NeComprendsPas: a l'objet qui a recu le message 
incompris, avec pour argument le nom du message incompris. 
L'objet a done l'opportunite de recuperer l'erreur : il suffit que 
sa classe detienne une methode de nom NeComprendsPas : . Si ce 
n'est pas le cas, une erreur fatale d'execution est declenchee. 

Le mecanisme de reponse a un message est dynamique et non 
type : seule compte la classe de l'objet receveur, qui determine 
le dictionnaire dans lequel la methode est recherchee. Un meme 
message peut done donner lieu a l'execution de methodes 
differentes s'il est recu par des objets de classes differentes. La 
classe des arguments n'intervient pas : si Ton veut imposer 
qu'un argument d'un message appartienne a une classe donnee, 
la methode correspondante doit faire les tests necessaires. 
Comme les classes sont des objets, on peut tester si la classe d'un 
objet est egale a une classe donnee. 

L'aspect dynamique de l'envoi de message apparait lorsque 
Ton modifie au cours de l'execution le dictionnaire des 
methodes d'une classe. Un message qui etait precedemment 
incompris peut etre defini en cours d'execution. Comme la 
definition de methode se fait par envoi de message, une 
methode peut definir d'autres methodes, de la meme facon 
qu'une fonction Lisp peut definir d'autres fonctions. 

Creer une classe 

II est temps de passer a un exemple, et de presenter 
1' implementation en Smalltalk de la classe Pile. Pour cette 
classe, nous utilisons la classe Tableau de l'environnement 
Smalltalk. Nous utilisons deux messages de cette classe : 

• le message en: qui permet d'acceder a un element de 
tableau, 

• le message en:mettre: qui permet de modifier la valeur d'un 
element de tableau. 
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classe 

superclasse 

champs 



Pile 
Objet 

pile sommet 



methodes 
Initialiser 

pile «- Tableau Nouveau. 

sommet «- 0. 
Empiler: unObjet 

sommet «- sommet + 1 . 

pile en: sommet mettre: unObjet. 
Depiler 

sommet «- sommet - 1 . 
Sommet 

t pile en: sommet. 

La classe Pile herite de la classe Objet, qui est une classe 
predefinie en Smalltalk. Une pile a deux champs : un tableau 
qui represente la pile, et l'indice du sommet de la pile dans le 
tableau. On peut referencer dans un corps de methode les 
arguments du message, ainsi que les noms des champs de la 
classe. Ces noms de champs font reference aux champs de 
l'objet receveur du message. 

Nous avons defini quatre methodes dans la classe Pile : 

• Initialiser initialise les champs de la pile ; le champ pile 
recoit un objet de la classe Tableau, et le champ sommet est 
initialise a 0. 

• Empiler est un message qui prend un objet en argument 
(l'objet a empiler). Notre pile est heterogene : aucun 
controle n'est fait sur la classe des objets empiles. On peut 
done empiler des objets de classes differentes. 

• Depiler enleve le sommet de pile. 

• Sommet retourne le sommet courant. 

Notre pile n'est pas tres sure : il n'y a pas de controle dans 
Depiler ni dans Sommet pour s'assurer que la pile n'est pas 
vide. Nous pourrons ajouter ces tests lorsque Ton aura decrit la 
facon de realiser des conditionnelles. 
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Pour utiliser la classe Pile, il suffit d'en creer une instance et 
de lui envoyer des messages : 

mapile «- Pile Nouveau. -- instanciation 
mapile Initialiser, 
mapile Empiler: 10. 
mapile Empiler: 15. 
mapile Depiler. 

s «- mapile Sommet. -- s contient 10 

o «- UneClasse Nouveau. 

mapile Empiler: o. 

mapile Empiler: mapile. -- !! 

La derniere instruction, pour surprenante qu'elle paraisse, est 
tout a fait correcte, puisque Ton peut empiler n'importe quel 
objet. 

4.3 HERITAGE 

L'axiome 3 indique que toute classe est sous-classe d'une 
autre classe. Cet axiome determine Varbre d'heritage qui lie les 
classes entre elles. Nous avons vu qu'une classe predefinie, 
Objet, faisait exception a cet axiome. Objet est la racine de 
l'arbre d'heritage, c'est-a-dire que, directement ou 
indirectement, toute classe est une sous-classe de Objet. 

L'heritage permet de definir une classe a partir d'une autre, 
en conservant les proprietes de la classe dont on herite. Une 
sous-classe est un enrichissement d'une classe existante : on 
peut ajouter de nouveaux champs et de nouvelles methodes. On 
peut egalement modifier le comportement de la classe de base 
en redefinissant des methodes. 

L'heritage modifie la recherche de methode que nous avons 
decrite dans la section precedente : lorsqu'un message est recu 
par un objet, celui recherche d'abord dans le dictionnaire des 
methodes de sa classe. S'il ne trouve pas de methode, il poursuit 
la recherche dans sa classe de base, et ainsi de suite jusqu'a 
trouver une methode ou bien atteindre la racine de l'arbre 
d'heritage, a savoir la classe Objet. 
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Figure 13 - Invocation de methode. 
Les fleches hachurees represented la recherche de methode. 
L'envoi de Depiler reussit, mais l'envoi de Coucou echoue 



Dans le cas ou le message n'a pas de methode associee, le 
message NeComprendsPas : est envoye au receveur du message, 
avec comme argument le nom du message incompris. La 
recherche d'une methode de nom NeComprendsPas : suit le 
meme mecanisme : recherche dans la classe de l'objet, puis ses 
superclasses successives. La classe predefinie Objet definit la 
methode NeComprendsPas, de telle sorte que Ton est assure de 
ne pas echouer cette fois-ci (figure 13). Cette technique de 
traitement des messages incompris permet a toute classe de 
redefinir la methode NeComprendsPas : et de realiser une 
recuperation d'erreur, sans introduire de mecanisme 
supplementaire dans le langage tel que la notion d'exception. 
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Definir une sous-classe 

Voyons comment definir une classe HPile, sous-classe de Pile, 
dans laquelle on force les elements a appartenir a une meme 
classe. II s'agit d'ajouter un champ qui stocke la classe des 
objets que Ton empile, ainsi qu'une methode qui permet 
d'affecter ce champ. Enfin, il faut redefinir la methode Empiler 
afin de realiser le controle de la classe de l'objet empile. 

Pour decrire cette classe, il nous faut introduire la 
conditionnelle, qui a la forme suivante : 

bool siVrai: [ blocSiVrai ] siFaux: [ blocSiFaux ] 

II s'agit de l'envoi du message siVrai: siFaux: a un objet de la 
classe Booleen. Les arguments du message sont deux blocs, 
correspondant aux actions a effectuer selon que l'objet receveur 
est l'objet vrai ou l'objet faux. Nous verrons plus loin comment 
sont definies la classe Booleen et les structures de controle telles 
que celle-ci. 

La definition de la classe HPile est la suivante : 

classe HPile 
superclasse Pile 
champs classe 
methodes 

Classe: uneClasse 

classe «- uneClasse. 
self Initialiser. 
Empiler: unObjet 

unObjet Classe = classe 

siVrai: [ super Empiler: unObjet ] 

siFaux: [ "Empiler: erreur de classe" Ecrire ] 

La methode Classe: permet de definir la classe des objets que 
Ton met dans la pile. Elle affecte le champ classe et execute self 
Initialiser. La methode Empiler: est redefinie de maniere a tester 
la classe de l'objet empile. Pour cela, on utilise la methode 
Classe, definie dans la classe Objet, qui retourne la classe de son 
receveur. Le receveur du message siVrai: siFaux: est le resultat 



76 Les langages a objets 



de l'expression unObjet Classe = classe. Cette expression se 
decompose en un envoi du message unaire Classe a unObjet. Le 
resultat est compare au champ classe par le message binaire =. 
Le bloc a executer si l'expression est vraie, c'est-a-dire si l'objet 
est de la classe attendue, est super Emptier. Si l'expression est 
fausse, un message d'erreur est emis en envoyant le message 
Ecrire a une chaine de caracteres. II nous reste a decrire self 
(utilise dans Classe:) et super (utilise dans Emptier :). 

Selfet Super 

Nous avons vu que le corps d'une methode s'execute dans le 
contexte de l'objet receveur du message. A l'interieur du corps 
d'une methode, on a directement acces aux champs de l'objet 
receveur. En revanche, si Ton veut envoyer un message au 
receveur lui-meme, il faut un moyen de le nommer. On utilise 
alors la pseudo-variable self, qui designe le receveur de la 
methode en cours d'execution. Ainsi, dans la methode Classe: 
ci-dessus, le receveur du message s'envoie a lui-meme (self) le 
message Initialiser. 

Lorsque Ton veut redefinir une methode dans une sous-classe, 
on a en general besoin d'utiliser la methode de meme nom 
definie dans la classe de base. Pour cela, on utilise une autre 
pseudo-variable, super, qui denote l'objet receveur en le 
considerant comme une instance de sa classe de base (ou 
superclasse, d'ou le nom de super). Ceci est illustre par la 
methode Empiler:. II s'agit de tester une condition (l'objet est-il 
de la bonne classe ?), et si celle-ci est satisfaite, d'empiler 
effectivement l'element. Pour cela, on envoie le message 
Empiler: a super. Si on l'envoyait a self, on aurait un appel 
recursif, ce qui n'est pas l'effet souhaite. L'envoi a super 
signifie que la recherche d'une methode pour le message 
Empiler commence a la superclasse du receveur, et non pas a sa 
classe comme c'est le cas normalement (figure 14). 

Dans la pratique, on utilise super seulement dans le corps 
d'une methode redefinie, comme nous venons de le faire. C'est 
en effet la seule situation dans laquelle il est justifie d'invoquer 
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Empiler 



Pile 

Empiler: v [... ] 

v J 







1 



Hpile 



- Empiler: v [ 

super Empiler: v 

] 



Figure 14 - Les pseudo-variables self et super 



1' implementation de la meme methode dans la classe de base. 
Utiliser super dans un autre contexte revient a transgresser la 
classe de l'objet receveur. 

L 'implementation de l'envoi de message 

L'heritage et la possibilite de modifier dynamiquement les 
dictionnaires des methodes impliquent que, pour chaque envoi 
de message, on effectue a l'execution une recherche dans la 
chaine des superclasses de la methode correspondant au 
message. II en resulte que l'envoi de message est tres cotiteux. 

Comme la hierarchie d'heritage et les dictionnaires de 
methodes changent peu par rapport au nombre de messages 
envoyes, une augmentation des performances importante est 
obtenue dans la plupart des implementations en utilisant un 
cache. Les entrees du cache sont constitutes de couples <nom 
de classe, selecteur de messago. Pour chaque entree, le cache 
contient le resultat de la recherche du message dans la classe et 
ses superclasses. Lors d'un envoi de message, on cherche dans 
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le cache une entree correspondant a la classe de l'objet receveur 
du message et au selecteur du message. Si l'entree n'est pas 
dans le cache on effectue la recherche dans les dictionnaires, et 
on entre le resultat dans le cache. Avec cette technique, on 
obtient facilement des taux de presence dans le cache de plus de 
98%, et une augmentation importante des performances. 

Le cache doit etre invalide, c'est-a-dire vide, chaque fois que 
l'arbre d'heritage ou un dictionnaire de methode change. 
Chaque ajout de classe ou de methode coute done cher. Aussi, 
diverses techniques permettent de ne pas invalider tout le cache 
afin de reduire le cout de ces modifications. 

4.4 LES STRUCTURES DE CONTROLE 

Un aspect original de Smalltalk est de ne pas contenir de 
structures de controle predefinies. Celles-ci sont definies par des 
classes et des methodes, a l'aide de la classe predefinie des blocs, 
comme nous allons l'illustrer ici. 

Les booleens et la conditionnelle 

Revenons tout d'abord sur la conditionnelle, que nous avons 
deja utilisee. Le receveur du message siVrai:siFaux: est un 
booleen ; selon sa valeur, e'est l'un des deux blocs arguments 
du message qui est execute. Pour produire cela, on definit trois 
classes et deux objets : 

• la classe Booleen, qui n'a aucune instance ; 

• la classe Vrai, sous-classe de Booleen, qui a une seule 
instance : l'objet vrai ; 

• la classe Faux, sous-classe de Booleen, qui a une seule 
instance : l'objet faux. 

Le receveur de siVrai:siFaux: ne peut etre que l'objet vrai ou 
l'objet faux. Ainsi, 1'evaluation de 3 < 4 retourne l'objet vrai, 
alors que 1=0 retourne l'objet faux. II suffit done de definir la 
methode siVrai:siFaux: dans chacune des classes Vrai et Faux : 
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classe Vrai 
superclasse Booleen 
champs 
methodes 

siVrai: blocVrai siFaux: blocFaux 
t blocVrai valeur. 

classe Faux 
superclasse Booleen 
champs 
methodes 

siVrai: blocVrai siFaux: blocFaux 
f blocFaux valeur. 

Comme on le voit, si l'objet vrai recoit un message 
siVrai:siFaux:, il retourne la valeur du premier argument ; si 
c'est l'objet faux qui recoit le message, il retourne la valeur du 
deuxieme argument. L'heritage nous a permis de reproduire un 
comportement conditionnel. Cette technique s' applique a 
d'autres messages, tels que les operateurs logiques : 



classe Vrai 
methodes 
non 

t faux, 
ou: unBool 

f vrai. 
et: unBool 

f unBool. 



classe Faux 
methodes 
non 

t vrai. 
ou: unBool 

t unBool. 
et: unBool 

t faux. 



La definition des methodes non, ou: et et: dans les deux 
classes Vrai et Faux permet d'implementer facilement les tables 
de verite de ces operateurs. La figure 15 illustre revaluation 
d'une expression booleenne qui utilise ces operateurs. 

Jusqu'ici la classe Booleen ne nous a pas servi : en fait Vrai et 
Faux auraient tres bien pu heriter directement de Objet. Nous 
allons maintenant utiliser la classe Booleen pour factoriser des 
methodes entre les classes Vrai et Faux : 
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classe Booleen 
superclasse Objet 
champs 
methodes 

siVrai: unBloc 

t self siVrai: unBloc siFaux: [ ]. 
siFaux: unBloc 

t self siVrai: [ ] siFaux: unBloc. 
xor: unBool 

f (self ou: unBool) 

et: ((self et: unBool) non). 

On a defini dans la classe Booleen deux conditionnelles 
siVrai: et siFaux:, qui correspondent a la conditionnelle 
siVrai:siFaux: lorsque Ton omet l'un des blocs. II est inutile de 
definir ces conditionnelles dans les deux classes Vrai et Faux, 
comme le montre la figure 16. De facon similaire, le ou exclusif 
(xor) est defini a partir des operateurs elementaires et:, ou: et 
non, selon l'expression : a xor b = (a ou b) et non (a et b). 
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Les blocs et les boucles 

En ce qui concerne les structures de boucles, ce n'est plus 
dans la classe Boole en que vont se faire les definitions, mais 
dans la classe des blocs. Decrivons tout d'abord la boucle tant- 
que : 

classe Bloc 
methodes 

tantQueVrai: corps 

(self valeur) siVrai: [ corps valeur. 

self tantQueVrai: corps ]. 

Le message tantQueVrai: s'utilise de la facon suivante : 
[x< 10 ] tantQueVrai: [s^s + x;x«^x-1 ] 

Le receveur est un bloc, car celui-ci doit etre evalue a chaque 
tour de boucle, comme le montre 1' implementation de la 
methode tantQueVrai: : le bloc receveur s'evalue ; s'il est vrai, 
le corps de la boucle est evalue, et l'iteration a lieu grace a 
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l'envoi (recursif) du message tantQueVrai: au bloc receveur. 
Comme toujours avec Smalltalk, il n'y a aucun controle de type 
et rien n'empeche d'ecrire : 

[ 10] tantQueVrai: [...]. 
"coucou" tantQueVrai: [ ... ]. 

Selon la valeur retournee par 1'evaluation du bloc receveur, 
une erreur aura lieu ou l'execution pourra continuer. Dans le 
premier cas, revaluation du bloc receveur retourne la valeur 10, 
de la classe Entier, qui ne sait repondre a siVrai:. Dans le 
deuxieme cas, le receveur est une chaine de caracteres, qui ne 
sait repondre au message valeur. Mais si Ton definissait ces 
methodes, l'execution pourrait se poursuivre. 

Le dernier type de structure de controle que nous allons 
examiner est l'iteration. II s'agit d'executer un corps de boucle 
(un bloc) un certain nombre de fois. Pour reproduire 
1' equivalent de la boucle iterative de Pascal, il faut definir une 
classe Intervalle, qui contient deux entiers representant les 
bornes inferieure et superieure de 1' intervalle. La methode 
repeter:, envoyee a un intervalle, realise l'iteration : 

classe Intervalle 
superclasse Objet 
champs inf sup 

methodes 
Inf: i Sup: s 

inf «- i. sup «- s. 
repeter: corps 
lil 

i «- inf. 

[ i < sup ] tantQueVrai: 
[ corps valeur: i. 
i«-i + 1 ]. 

La methode Inf: Sup: permet d'initialiser les bornes de 
l'intervalle. La methode repeter: introduit une variable locale /. 
Cette variable sert de compteur de boucle, et Ton utilise le 
message tantQueVrai: des blocs pour realiser l'iteration. 



Smalltalk et ses derives 8 3 



Le message repeter: s'utilise comme suit : 

bornes «- Intervalle Nouveau. 
bornes Inf: 10 Sup: 20. 
s^O. 

bornes repeter [ :x I s *- s + x ]. 

s Ecrire. -s = 165 

Pour faciliter l'ecriture de 1'iteration, nous allons ajouter un 
message dans la classe predefinie Entier : 

classe Entier 
methodes 

a: val t (Intervalle Nouveau) Inf: self Sup: val. 

Ce message permet de creer un intervalle en envoyant a un 
entier le message a: avec un entier en argument. Le receveur est 
la borne inferieure de l'intervalle, l'argument la borne 
superieure. L'exemple precedent s'ecrit alors : 

s^O. 

(10 a: 20) repeter [ :x I s *- s + x ]. 
s Ecrire. 

L'expression 10 a: 20 retourne un intervalle auquel on envoie 
le message d'iteration repeter. 

Cette technique d'iteration s'applique a de nombreuses 
classes. Ainsi, Smalltalk fournit un grand nombre de classes 
conteneurs pour le stockage d'objets (tableaux, listes, ensembles, 
dictionnaires, etc.). La plupart de ces classes definissent une 
methode qui permet l'iteration de leurs elements. 

Nous pouvons appliquer cela a notre classe Pile, en lui 
ajoutant une methode repeter: qui evalue un bloc pour les 
elements successifs de la pile : 

classe Pile 
methodes 

repeter: unBloc 

(1 a: sommet) repeter: 

[ :i I unBloc valeur: (pile en: i) ]. 
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On utilise un intervalle cree par le message a: representant 
l'ensemble des indices valides de la pile. L'intervalle est 
enumere par la methode repeter:. Pour chaque element de 
l'intervalle, on evalue le bloc argument avec comme parametre 
1' element de pile. 

Pour imprimer le contenu d'une pile, il suffit d'ecrire : 

pile «- Pile Nouveau. 
pile Initialiser. 
-- empiler des elements ... 
pile repeter: [ :e I e Ecrire ]. 

Nous avons defini la methode repeter: dans la classe Pile a 
l'aide de la methode repeter: de la classe Intervalle, c'est-a-dire 
que Ton utilise le polymorphisme ad hoc, intrinseque aux 
langages objets. Ceci nous permet par exemple de definir dans 
la classe Objet elle-meme une methode qui imprime le contenu 
d'un objet de la facon suivante : 

classe Objet 
methodes 

EcrireContenu 

self repeter: [ :e I e Ecrire ]. 

Tout objet qui sait repondre a repeter: pourra executer 
EcrireContenu : 

(10 a: 20) EcrireContenu. 
pile «- Pile Nouveau. 
pile Initialiser. 
-- empiler des elements ... 
pile EcrireContenu. 

Dans cette section, nous avons defini l'iteration (message 
repeter:) de la classe Pile en fonction de l'iteration des 
intervalles. Celle-ci est definie en fonction de la repetition des 
blocs (tantQueVrai:), elle-meme definie recursivement a l'aide 
de la conditionnelle siVrai:. Enfin cette conditionnelle est 
definie en fonction de la conditionnelle generale siVrai.siFaux:, 
definie dans les deux classes Vrai et Faux. 
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Cet exemple illustre la souplesse et la puissance de Smalltalk, 
grace a 1' utilisation extensive de la liaison dynamique : il suffit 
de rajouter des methodes a une classe (comme repeter: dans la 
classe Pile), pour que les instances de cette classe soient dotees 
de nouvelles capacites (comme EcrireContenu). Ceci fait de 
Smalltalk un environnement ideal pour le maquettage et le 
prototypage d' applications. En revanche, l'absence de typage, 
done d' assurance a priori qu'un programme ne declenchera pas 
d'execution de messages indefinis, est souvent un obstacle a la 
realisation d' applications finales. 

4.5 METACLASSES 

Nous avons vu des la presentation des axiomes de base de 
Smalltalk que toute classe est un objet, et appartient done a une 
classe, appelee metaclasse. Cette caracteristique est a la base de 
nombreuses possibilites interessantes dans Smalltalk. 

En premier lieu, la notion de metaclasse permet de realiser 
l'instanciation par un envoi de message : l'envoi du message 
Nouveau a une classe retourne une instance de cette classe. Le 
message etant envoye a une classe, e'est dans sa metaclasse 
qu'est cherchee la methode correspondante (figure 17). 

La metaclasse ne sert pas seulement a l'instanciation. En effet, 
une classe contient la definition de ses instances, e'est-a-dire la 
liste des noms de champs et le dictionnaire des methodes. On 
peut done interroger la classe pour savoir si une methode 
particuliere est definie, pour modifier le dictionnaire des 
methodes, et pour definir de nouvelles sous-classes. Une 
metaclasse definit pour cela les methodes Connait:, Superclasse 
et DeriveDe:. Le message Connait: permet de savoir si une 
classe sait repondre au message dont le nom est passe en 
argument. Le message Superclasse retourne la classe de base de 
la classe receveur, et enfin le message DeriveDe: permet de tester 
si la classe receveur est une classe derivee de la classe dont le 
nom est passe en parametre. Voici quelques exemples 
d'utilisation de ces messages : 
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(T) No 



V J 




Nouveau 



Figure 17 - Creation d'un objet : utilisation de la metaclasse 



Pile ConnaTt: "Empiler:". --vrai 

Pile ConnaTt: "SiVrai:". -- faux 

Vrai Superclasse. -- Booleen 

Vrai DeriveDe: "Pile". -- faux 

HPile DeriveDe: "Objet". --vrai 

Le corps des methodes correspondant a ces messages se trouve 
dans le dictionnaire des methodes de la metaclasse de leur 
receveur, comme le prouvent les exemples suivants : 

Pile ConnaTt: "Nouveau". --faux 
(Pile Classe) ConnaTt: "Nouveau". --vrai 

Dans le cas de Smalltalk, plusieurs modeles de metaclasses ont 
ete experimentes. Le plus simple comprenait une seule 
metaclasse dans le systeme, nommee Classe. Dans les versions 
suivantes de Smalltalk, cela s'est avere etre une limitation, car on 
ne pouvait differencier les metaclasses de classes distinctes. Le 
modele de Smalltalk-80 definit une metaclasse par classe, et la 
hierarchie d'heritage des metaclasses suit celle des classes. 
Chaque classe est l'unique instance de sa metaclasse. Pour 



Smalltalk et ses derives 8 7 




V J 

Figure 18 - Le modele des metaclasses de Smalltalk-80 

l'utilisateur, les metaclasses sont transparentes car elles sont 
creees automatiquement par la methode de definition de classe. 

Par convention, nous appellerons ClasseX la metaclasse de la 
classe X. La metaclasse de Objet est done ClasseObjet, celle de 
Pile est ClassePile. Comme Pile herite de Objet, ClassePile 
herite de ClasseObjet. Les metaclasses heritent de Classe, qui 
elle-meme herite de Objet. 

Le mecanisme des metaclasses induit une regression a l'infini. 
En effet, une metaclasse est aussi un objet, qui a done une classe, 
une metaclasse, etc. Comme dans le cas de la hierarchie 
d'heritage, cette regression est artificiellement interrompue par 
un bouclage dans le chainage des metaclasses : dans Smalltalk- 
80, toutes les metaclasses heritent de la classe Classe, et sont des 
instances de MetaClasse, selon le schema de la figure 18. 
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Du point de vue du programmeur, cet artifice est de peu 
d'importance. II assure au langage la meta-circularite , c'est-a- 
dire la capacite a se decrire lui-meme. Grace aux metaclasses on 
peut ecrire un interprete Smalltalk en Smalltalk. 

L'interet des metaclasses pour le programmeur 

Pour le programmeur, les metaclasses permettent d'une part 
de definir des methodes de classe, et d' autre part de partager des 
champs entre toutes les instances d'une classe. 

Les methodes de classe sont des methodes definies dans une 
metaclasse, et qui sont utilisees lorsque Ton envoie des messages 
a une classe. L' utilisation la plus repandue des methodes de 
classe est la redefinition de la methode d'instanciation Nouveau, 
et la definition d'autres methodes d'instanciation prenant des 
parametres. On peut rapprocher cela des constructeurs de 
certains langages a objets types (voir chapitre 3, section 3.6). 

Reprenons le cas de la classe Pile. Nous avons defini dans 
cette classe la methode Initialiser qui permet d'instancier et 
d'initialiser les champs de la pile. Lors de l'utilisation de la 
classe Pile, il faut s'assurer d'initialiser chaque pile apres l'avoir 
instanciee avec Nouveau : 

pile «- Pile Nouveau. 
pile Initialiser. 

Si Ton oublie l'initialisation, la pile ne pourra pas fonctionner 
comme prevu. II serait plus sur d'assurer l'initialisation lors de 
l'instanciation. II suffit pour cela de redefinir la methode 
Nouveau, de la facon suivante : 

classe ClassePile 
methodes 
Nouveau 
I pile I 

pile «- super Nouveau. 
pile Initialiser, 
t pile. 
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Figure 19 - Heritage des methodes de classes 



Cette methode est definie dans la metaclasse de Pile, puisque 
c'est la classe Pile qui recevra le message Nouveau. Cette 
methode commence par instancier la pile en s' envoy ant le 
message Nouveau. Nouveau va done etre envoye a la metaclasse 
ClassePile, consideree comme instance de sa classe de base 
ClasseObjet. Cela va invoquer la methode Nouveau definie pour 
tous les objets dans la metaclasse Classe. La pile resultante est 
ensuite initialisee : le message Initialiser est envoye a la pile, 
c'est done la methode Initialiser que nous avons ecrite dans la 
classe Pile qui va etre invoquee. Enfin la pile initialisee est 
retournee. On aurait pu condenser le corps de la methode en : 

t super Nouveau Initialiser. 

Dans le corps de cette methode, on n'a pas acces aux champs 
de l'objet pile. II est done impossible d'initialiser ces champs 
autrement que par l'envoi d'un message a la pile. 

D'autre part, comme on a redefini la methode Nouveau, toute 
classe qui herite de Pile utilisera egalement cette methode 
redefinie, grace au parallelisme entre l'heritage des classes et 
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celui des metaclasses. Par exemple, l'instanciation de la classe 
HPile assurera son initialisation, comme le montre la figure 19. 

Les metaclasses permettent egalement de definir des methodes 
d'instanciation avec parametres. Dans l'exemple suivant, on 
definit une methode d'instanciation qui permet de donner la 
taille de la pile a sa creation : 

classe Pile 
methodes 

Initialiser: taille 

pile «- Tableau Nouveau: taille. 

sommet «- 0. 

classe ClassePile 
methodes 

Nouveau: taille 

t super Nouveau Initialiser: taille. 

On ajoute a la classe Pile une methode Initialiser: qui prend la 
taille de la pile ; cet argument est transmis a la methode 
Nouveau: de la classe Tableau. On definit ensuite la methode 
Nouveau: dans la metaclasse de Pile, qui instancie une pile et 
l'initialise avec la taille donnee. Cette methode Nouveau: est un 
message binaire qu'il ne faut pas confondre avec le message 
unaire Nouveau que nous avons utilise jusqu'a present. Une fois 
definie cette methode de classe, l'utilisation d'une pile devient : 

pile «- Pile Nouveau: 100. 
pile Empiler: 10. 

Selon le meme mecanisme, on pourrait definir une methode 
d'instanciation pour la classe HPile qui prenne en parametre la 
classe des objets de la pile homogene. 

Variables de classe 

L'autre utilisation des metaclasses concerne la possibilite de 
definir de nouveaux champs dans une classe. De fait, ces 
champs sont accessibles par toutes les instances d'une classe 
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(toute instance connait sa classe) et jouent le role de variables 
globales d'une classe. 

Pour illustrer cela, nous allons creer une classe d'objets dont 
les instances ont un numero unique. La metaclasse a un champ 
qui est incremente a chaque instanciation : 

classe Demo 
superclasse Objet 
champs numero 
methodes 
Initialiser: n 

numero «- n. 
Numero 

t numero. 

classe ClasseDemo 
champs nb 
methodes 
Nouveau 

nb «- nb + 1 . 

t (super Nouveau) Initialiser: nb. 

La classe Demo contient un champ stockant le numero unique 
de l'instance, une methode d'initialisation, et une methode qui 
retourne le numero de l'objet. On ajoute a la metaclasse de 
Demo une variable de classe nb, et on redefinit la methode 
d' instanciation Nouveau. Cette methode incremente la variable 
de classe nb, puis instancie l'objet et l'initialise avec la valeur de 
nb. 

4.6 LES DERIVES DE SMALLTALK 

Smalltalk, influence par Lisp, est a l'origine d'une famille de 
langages a objets implementes au-dessus de Lisp. II s'avere en 
effet que 1' implementation des mecanismes des langages a 
objets en Lisp est relativement aisee, et fournit un terrain 
d' experimentation de nouveaux concepts. 
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Parmi les plus anciennes extensions de Lisp avec des objets, on 
trouve Flavors, qui a servi a implementer le systeme 
d' exploitation des machines Symbolics au debut des annees 80. 
Plus recemment, CLOS (Common Lisp Object System) a repris 
et etendu le modele des Flavors dans le but de definir une 
norme de Lisp a objets. Ceyx et ObjVLisp represented l'ecole 
francaise : Ceyx a ete developpe vers 1985 au-dessus de 
Le_Lisp par Jean-Marie Hullot, et ObjVLisp, un peu plus ancien, 
est l'objet des travaux de Pierre Cointe a partir de VLisp, un 
dialecte de Lisp developpe par Patrick Greussay a l'Universite 
de Vincennes. 

Tous ces langages precedent de principes similaires : il s'agit 
d' extensions de Lisp, c'est-a-dire que le programmeur utilise 
des fonctions Lisp pour ecrire ses programmes 2 . L'effet n'est 
pas toujours heureux car le style fonctionnel est assez 
radicalement different du style de la programmation par objets. 

Ces langages fournissent en general trois fonctions de base : la 
creation d'une nouvelle classe, la creation d'une instance, et 
l'envoi d'un message a un objet. La fonction de creation d'une 
classe permet de specifier son heritage (simple ou multiple), ses 
variables d'instances, ses methodes, et eventuellement sa 
metaclasse. En general, le systeme est capable de generer 
automatiquement des fonctions d'acces aux variables 
d'instance. En effet, celles-ci sont stockees dans une liste 
associee a l'atome qui represente l'objet, et elles ne peuvent etre 
accedees autrement que par une fonction. Cet artifice est 
neanmoins pratiquement transparent pour l'utilisateur, comme 
le montre l'exemple ci-dessous : 

(def-classe Pile (Objet) -- classe, superclasse 
(pile sommef)) -- variables d'instance 



1 La suite de cette section necessite en consequence quelques notions 
elementaires de Lisp. Nous esperons cependant ne pas trop ennuyer le lecteur 
peu familier avec Lisp en limitant les exemples. 



Smalltalk et ses derives 9 3 



(def-methode 

(Empiler Pile) (objet) -- methode, classe, arguments 
(setq sommet (+ sommet 1)) 
(envoi 'mettre pile sommet objet)) 

Dans cet exemple, dont la syntaxe est inspiree de Flavors, def- 
classe definit une nouvelle classe, et def-methode une nouvelle 
methode dans une classe existante. Le corps de la methode 
Empiler est constitute de deux expressions : 1' affectation {setq en 
Lisp) du champ sommet et l'envoi du message mettre au champ 
pile. Ce message est suppose stocker l'objet passe en second 
argument a l'indice passe en premier argument. L'envoi de 
message est une fonction qui s'invoque de la maniere suivante : 

(envoi 'message receveur arg1 arg2 ... argn) 

On peut retrouver une syntaxe plus proche de celle de 
Smalltalk en transformant chaque objet en une fonction, ce que 
font certains langages. L'envoi de message s'ecrit alors : 

(receveur message arg1 arg2 ... argn) 

La creation d'une pile et l'empilement d'un element se font 
de la maniere suivante : 

(setq mapile (instancier 'Pile)) 
(envoi 'Initialiser mapile) 
(envoi 'Empiler mapile 10) 

La fonction instancier realise l'instanciation d'une classe. La 
methode Initialiser est definie comme suit : 

(def-methode 

(Initialiser Pile) () -- methode, classe, arguments 
(setq pile (instancier Tableau)) 
(setq sommet 0)) 

L'interet d'utiliser Lisp comme langage de base est de 
disposer d'un environnement deja important qui simplifie 
1' implementation des mecanismes d'objets. La souplesse de 
Lisp permet egalement d'experimenter facilement de nouvelles 
fonctionnalites et des extensions au modele general des objets. 
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Les demons des Flavors 

Ainsi les Flavors fournissent des mecanismes sophistiques 
pour l'heritage multiple. On a vu que l'heritage multiple 
provoquait des conflits de noms lorsque plusieurs classes de 
base definissent une methode de meme nom. Les Flavors 
permettent de determiner, pour chaque classe, l'ordre de 
parcours du graphe des superclasses pour determiner la bonne 
methode a invoquer. II est egalement possible de combiner 
l'ensemble des methodes de meme nom heritees, c'est-a-dire de 
les invoquer l'une apres 1' autre. Enfin, on peut definir des 
demons, qui sont des methodes speciales associees aux methodes 
ordinaires. Lorsque la methode ordinaire est invoquee, tous les 
demons qui lui sont associes dans la classe ou dans ses 
superclasses sont egalement automatiquement invoques, selon 
un ordre que le programmeur peut controler. Par exemple, pour 
tracer les invocations du message Emptier, il suffit d'ajouter le 
demon suivant : 

(def-demon 

(Empiler Pile) (objet) -- methode, classe, arguments 
(print "on Empile " objet)) 

Meme si Ton redefinit Empiler dans une sous-classe de Pile, le 
demon sera appele. Dans la pratique, la combinaison de 
methodes et les demons sont des mecanismes extremement 
puissants, qui sont par la meme difficile a maitriser : l'envoi 
d'un message a un objet peut declencher une quantite d'effets 
dont l'origine risque d'etre difficile a identifier. De la meme 
facon, une modification locale du systeme, comme l'ajout ou le 
retrait d'un demon, peut provoquer des effets rapidement 
incontrolables. Les programmeurs Lisp sont coutumiers de ce 
genre de phenomenes, et trouveront dans ces langages un terrain 
d' experimentation encore plus vaste. 

Les metaclasses d'ObjVLisp 

Nous terminerons cette revue des derives de Lisp par 
ObjVLisp et son modele de metaclasses. En effet, ce langage 
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unePile 



uneTour 



Figure 20 - Le modele de metaclasses de ObjVLisp 

offre ce que Ton peut considerer comme le modele a la fois le 
plus simple et le plus ouvert de metaclasses (figure 20). 

Les classes Classe et Objet sont les deux classes primitives du 
systeme. Objet est une instance de Classe, et Classe est une sous- 
classe de Objet. Objet n'a pas de superclasse, alors que Classe 
est sa propre instance. Objet est la racine de l'arbre d'heritage, 
tandis que Classe est la racine de l'arbre d'instanciation. Toute 
classe doit done heriter indirectement de Objet, et etre l'instance 
de Classe ou d'une classe derivee de Classe. Ce dernier point 
correspond a la creation de metaclasses, sans les contraintes 
imposees par Smalltalk-80. Dans la figure 20, Pile et Tour ont la 
meme metaclasse alors qu'avec Smalltalk-80, chacune d'elles 
aurait sa propre metaclasse. Dans cet exemple, il est utile de 
n'avoir qu'une metaclasse car la meme methode d'instanciation 
convient aux deux classes. D'un autre cote, le modele de 
Smalltalk-80 permet de rendre les classes transparentes a 
l'utilisateur grace a la bijection entre classes et metaclasses, ce 
qui n'est pas le cas d'ObjVLisp. 
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4.7 CONCLUSION 

Smalltalk est sans conteste le langage qui est a l'origine du 
succes du modele des objets. Tres rapidement, le langage a ete 
valide par la realisation d'applications importantes, en 
particulier l'environnement de programmation Smalltalk. De 
leur cote, les extensions de Lisp par les objets ont permis 
d' experimenter et de mieux comprendre les mecanismes des 
langages a objets. 

La puissance de Smalltalk est aussi sa principale faiblesse : 
avec la liaison dynamique et l'absence de typage statique, il est 
impossible de s'assurer de la correction d'un programme avant 
son execution, ni meme apres. De plus, l'absence de mecanisme 
de protection des acces (toute methode est accessible par tout le 
monde) n'ajoute pas a la securite de programmation. Des 
extensions de Smalltalk ont introduit avec succes la declaration 
des classes des arguments et des variables locales. Dans CLOS, 
les types des arguments des methodes doivent etre declares. 
Dans les deux cas, la perte de fonctionnalite est minime, et, dans 
CLOS, le typage permet meme d'introduire des methodes 
generiques et d'augmenter ainsi la puissance du langage. 

L'autre faiblesse de Smalltalk et des langages interpretes en 
general est le manque d'efficacite a l'execution. La encore, de 
nombreux travaux ont permis d'augmenter les performances de 
facon spectaculaire. Des mesures ont meme montre que, pour 
certaines applications, la difference de performance entre 
Smalltalk et un langage a objets type et compile n'etait pas 
significative. Dans d'autres cas, la difference est redhibitoire, ce 
qui ne fait que confirmer qu'il n'existe pas de langage 
universel. Smalltalk en tout cas reste un langage privilegie pour 
decouvrir les concepts des langages a objets, mais aussi pour 
developper des prototypes et, dans certains cas, des applications 
finales. 



Chapitre 5 



PROTOTYPES 
ET ACTEURS 



Ce chapitre presente deux variations importantes des idees de 
base des langages a objets. Les langages de prototypes font 
disparaitre la difference entre classes et instances en introduisant 
la notion unique d'objet prototype. lis remplacent la notion 
d'heritage par celle de delegation. Les langages d'acteurs 
generalised la notion d'envoi de message pour l'adapter a la 
programmation parallele : l'envoi de message n'est plus une 
invocation de methode, mais une requete envoyee a un objet. 

5.1 LANGAGES DE PROTOTYPES 

Les langages a objets que nous avons presentes jusqu'a 
present etaient tous fondes sur les notions de classe, d'instance 
et d'heritage. Ces trois notions induisent deux relations entre les 
entites du langage : la relation d'instanciation entre un objet et 
sa classe, et la relation d'heritage entre une classe et sa classe de 
base. Pour distinguer ces langages a objets classiques des 
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langages de prototypes, nous appellerons les premiers langages 
de classes. 

Les premiers travaux sur les langages de prototypes datent de 
1986 ; ils sont dus a Henry Lieberman du MIT, qui a la meme 
epoque a aussi travaille sur les langages d'acteurs. Le langage 
qui a inspire cette presentation s'appelle Self, cree et developpe 
depuis 1987 par David Ungar et Randall Smith a l'universite de 
Stanford. II represente l'etape la plus avancee dans le domaine 
des langages de prototypes. 

Prototypes et clonage 

Dans un langage de prototypes, il n'y a pas de difference 
entre classes et instances : tout objet est un prototype qui peut 
servir de modele pour creer d'autres objets. L' operation qui 
permet de creer un nouvel objet a partir d'un prototype 
s'appelle le clonage, et consiste a recopier l'objet clone. 

Dans un prototype, l'etat et le comportement sont confondus : 
il n'y a pas de difference entre champs et methodes, appeles 
indistinctement cases (« slots » en anglais). Pour acceder au 
champ x, un prototype s'envoie le message x. Pour modifier le 
champ x, il s'envoie le message x: avec la nouvelle valeur en 
argument. 

Nous declarons un prototype par une liste de couples nom de 
case / valeur, entouree d' accolades. Les champs ont pour valeur 
une expression tandis que les methodes ont pour valeur un bloc 
(note entre crochets, comme en Smalltalk). Un prototype de pile 
aura ainsi 1' aspect suivant : 



Pile «-{ 
pile 

sommet 

Empiler: unObjet 



Tableau doner. 
0. 

[ sommet: (sommet + 1 ). 
pile en: sommet mettre: unObjet ]. 
[ sommet: (sommet - 1) ]. 
[ T pile en: sommet ]. 



Depiler 
Sommet 



} 
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Pile 



pile [ 



sommet 0 
Initialiser 
Depiler 
Sommet 



P1 



pile HoT 

sommet 1 
Initialiser 
Depiler 
Sommet 



P2 



pile 1 1Q|20| 
sommet 2 
Initialiser 
Depiler 
Sommet 



Figure 21 - Le prototype Pile et deux clones 



Les cases pile et sommet sont des champs. Leurs valeurs 
correspondent aux valeurs initiales a la creation du prototype. 
Les messages d'acces pile et sommet, et les messages 
d'affectation pile: et sommet: sont implicitement crees. Les 
autres cases sont des methodes. Comme tous les acces aux 
champs se font par messages, la pseudo-variable self est le 
receveur implicite des messages. La methode Depiler pourrait 
s'ecrire sous la forme : 

Depiler [ self sommet: (self sommet - 1 ) ]. 

Dans cet exemple, Pile est un prototype, done un objet 
directement utilisable. Nous allons utiliser Pile comme un 
modele pour creer et manipuler deux piles (figure 21) : 

p1 «- Pile doner. 
p1 Empiler: 10. 

x «- p1 Sommet. -- x vaut 1 0 

p2 *- p1 doner. - p2 contient deja 10 

p2 Empiler: 20. 

Dans un langage de classes, une classe contient une 
description de ses instances. Dans un langage de prototypes, tout 
objet est un exemplaire qui peut etre reproduit par clonage. 
Comme on le voit dans 1' exemple ci-dessus, ce mecanisme 
simplifie l'initialisation des objets : il suffit d'initialiser 
correctement le prototype qui sert de modele. A titre de 
comparaison, Smalltalk exige de redefinir la methode 
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d'instanciation definie dans la metaclasse ; avec les langages a 
objets types, il faut introduire des mecanismes specifiques tels 
que les constructeurs de C++. 

La delegation 

Le clonage consiste en la duplication exacte d'un prototype 
dans son etat courant. Cela signifie que l'etat et le 
comportement sont copies et qu'il n'y a pas de lien entre 
l'objet qui sert de modele et l'objet resultant du clonage, 
comme illustre dans la figure 21. II n'y a done pas de possibilite 
de partage entre les objets. Dans les langages de classes, le 
partage existe a deux niveaux : 

• par le lien d'instanciation entre un objet et sa classe, toutes 
les instances d'une classe partagent le meme comportement, 
decrit dans la classe. 

• par le lien d'heritage entre une classe et sa superclasse, les 
classes derivees partagent les descriptions contenues dans 
leurs superclasses. 

Dans les langages de prototypes, un mecanisme unique, la 
delegation, permet a des objets de partager des informations. Un 
objet peut deleguer a un autre objet, appele parent, les messages 
qu'il ne comprend pas. Dans l'exemple de la pile, nous allons 
partager les methodes Emptier, Depiler et Sommet en les mettant 
dans un prototype a part, qui deviendra le parent de tous les 
clones de la pile. Lorsque l'un de ces messages sera envoye a un 
clone de la pile, il sera delegue a son prototype, dans ce cas 
protoPile. 

protoPile ^{ 

Empiler: unObjet [ sommet: (sommet + 1 ). 

pile en: sommet mettre: unObjet ]. 
Depiler [ sommet: (sommet - 1 ) ]. 

Sommet [ \ pile en: sommet ]. 

} 



Le prototype de la pile s'ecrit maintenant comme suit 
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Empiler 
Depiler 
Sommet 




P2 



pile 1 10|20| I 
sommet 2 



Figure 22 - Partage de methodes avec les prototypes. 
Les fleches noires indiquent le parent (qui est un champ). 
Les fleches blanches indiquent les operations de clonage 



Pile «-{ 

parent protoPile. 



pile Tableau doner, 

sommet 0. 



} 



Lorsque Ton clone un prototype, les objets crees ont le meme 
parent que leur prototype. Dans notre exemple, les clones de 
Pile ont pour parent protoPile. L'exemple d'utilisation vu plus 
haut est toujours valable, mais le schema des objets a l'execution 
change, comme le montre la figure 22. Lorsque Ton envoie le 
message Empiler hpl,i\ est delegue a son parent protoPile. 

Dans cet exemple, le couple (Pile, protoPile) joue le role 
d'une classe dans un langage de classes. Le lien d'instanciation 
entre un objet et sa classe est realise par la delegation. 
L'instanciation se fait par clonage, mais on pourrait aisement 
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simuler le mecanisme des langages de classe en definissant dans 
protoPile la methode Nouveau, qui aurait pour valeur 

[ f Pile doner]. 

Cet exemple montre egalement pourquoi l'acces aux champs 
se fait par message : dans les corps des methodes de protoPile, 
on fait reference a des champs (sommet, pile) qui sont declares 
dans Pile, done inconnus de protoPile. 

Dans la suite, nous utiliserons le terme « classe » pour parler 
d'un prototype qui contient exclusivement des methodes. II faut 
neanmoins garder a l'esprit qu'une classe n'est pas une notion 
distincte dans les langages de protoypes. 

Simuler l'heritage avec la delegation 

Nous allons maintenant illustrer l'utilisation de la delegation 
pour simuler l'heritage. Reprenons pour cela l'exemple des 
Tours de Hanoi. Une tour est une pile qui doit controler la taille 
des objets empiles. On cree done un prototype Tour qui a pour 
parent le prototype protoTour, qui a lui-meme pour parent 
protoPile. 

protoTour «- { 

parent protoPile. 
Empiler: unObjet [ 
unObjet < Sommet 

siVrai: [ parent Empiler: unObjet ] 

siFaux: [ "Empiler: objet trop grand" Ecrire ] 

]■ 

} 

Tour «- (Pile doner) parent: protoTour. 

Nous avons defini dans ce nouveau prototype une methode 
Empiler: qui, selon la taille de l'objet, demande a son parent de 
realiser l'empilement ou affiche un message d'erreur. Le 
prototype Tour est cree par clonage du prototype Pile, en 
changeant son parent. L'utilisation de Tour est illustree par 
l'exemple suivant et la figure 23. 
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r 



protoPile 




Pile 



Empiler 
Depiler 
Sommet 




t 



Empiler 



pile 

sommet 



pile 

sommet 



Figure 23 - Simulation de l'heritage par la delegation. 
Les Heches ont la meme signification que pour la figure 22 



t «- Tour doner, 
t Empiler: 10. 



L'exemple de la pile que nous venons de presenter permet de 
faire le parallele entre les langages de prototypes et les langages 
de classes. Mais l'interet des prototypes est d'etendre les 
possibilites des langages de classes. Les prototypes permettent 
ainsi, entre autres, de creer des objets dotes de comportements 
exceptionnels, d'avoir des champs calcules, et de faire de 
l'heritage dynamique. Nous allons maintenant illustrer ces 
differentes possibilites. 

Comportements exceptionnels 

Dans l'exemple de la tour, si notre application utilise une 
seule tour, on peut creer un objet qui a le comportement d'une 
tour sans pour autant creer la classe correspondante. II suffit de 
redefinir la case Empiler: dans l'objet lui-meme : 



t Empiler: 20. 



-- Empiler: objet trop grand 
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t-{ 

parent protoPile. 
pile Tableau doner, 

sommet 0. 
Empiler: unObjet [ 
unObjet < Sommet 

siVrai: [ parent Empiler: unObjet ] 

siFaux: [ "Empiler: objet trop grand" Ecrire ] 

]■ 

} 

t Empiler: 10. 

t Empiler: 20. -- Empiler: objet trop grand 

Cet exemple montre comment creer des objets avec des 
comportements exceptionnels. Les objets vrai et faux de 
Smalltalk sont un autre exemple d' application : la ou nous 
avions cree deux classes Vrai et Faux, avec chacune une instance 
unique, il nous suffit de creer deux prototypes vrai etfaux, 
contenant chacun une version de la methode siVrai: siFaux:. On 
peut noter que de tels objets peuvent etre clones, les clones 
disposant egalement du comportement exceptionnel. 

Une autre application des comportements exceptionnels est la 
mise au point de programme. Si Ton veut suivre le 
comportement d'un objet precis, on peut definir une methode 
dans l'objet de la facon suivante (nous utilisons la methode 
ajoute: qui permet d'ajouter des cases dans un objet) : 

p «- Pile doner ajoute: { 
Empiler: unObjet [ 
"p Empiler" Ecrire. 
parent Empiler: unObjet 

] 

} 

Tout empilement sur p provoquera un message. Dans un 
langage de classes, l'ajout d'une trace dans la methode Empiler 
de la classe Pile provoquerait l'ecriture du message pour tout 
objet de la classe Pile. 
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Champs calcules 



L'acces aux champs d'un prototype par envoi de message 
permet de definir des champs dont la valeur est calculee et non 
pas stockee dans l'objet. Pour illustrer cela, definissons un 
prototype protoPoint qui contient des methodes de 
manipulation de points, et deux prototypes de points : l'un dont 
la position est stockee en coordonnees cartesiennes (Cartesien), 
l'autre en coordonnees polaires (Polaire) : 

protoPoint «- { 

Ecrire [ x Ecrire. ", " Ecrire. y Ecrire ]. 
+: p [ t doner x: (x + p x) y: (y + p y) ]. 

} 

La methode +: cree un nouveau point dont les coordonnees 
sont la somme des coordonnees du receveur et de l'argument. 

Cartesien «- { Polaire «- { 

parent protoPoint. parent protoPoint. 

x 0. rho 0. 

y 0. theta 0. 

} } 

Malheureusement, le prototype Polaire est inutilisable car les 
methodes de protoPoint utilisent les champs x et y. Pour 
remedier a cette situation, il suffit d'ajouter les methodes x, y, x: 
et y: a Polaire pour simuler les champs absents, grace aux 
equations suivantes : 

x = pcos€9 p = V(x 2 + y 2 ) 
y = p sin €9 6 = atan (y / x) 

De l'exterieur, tout ce passe comme si Polaire avait les 
champs x et y, qui sont en realite calcules a partir des 
coordonnees polaires stockees dans l'objet. 



Polaire «- { 

parent protoPoint. 

rho 0. 

theta 0. 
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y 

x: val 
y: val 



x 



[ t rho * theta cos ]. 
[ t rho * theta sin ]. 

[ rho: (val * val + y * y) sqrt. theta: (y / val) atan ]. 
[ rho: (x * x + val* val) sqrt. theta: (val / x) atan ]. 



} 



On pourrait de facon similaire ajouter les champs calcules rho 
et theta au prototype Cartesien. Cela permettrait d'utiliser les 
coordonnees les plus adequates dans les methodes de 
protoPoint. 

Heritage dynamique 

Le parent d'un prototype est une case similaire aux autres, a 
l'exception de son role particulier pour la delegation lors de 
l'envoi de messages. Rien n'interdit done de modifier la valeur 
de la case qui contient le parent d'un objet apres la creation de 
celui-ci : e'est Vheritage dynamique. Ainsi, en utilisant les 
definitions de Pile et de Tour vues plus haut, on peut 
transformer une tour en pile en affectant sa case parent : 

t «- Tour doner, 
t Empiler: 10. 

t Empiler: 20. -- Empiler: objet trop grand 

t parent: Pile. -- la tour devient une pile 

t Empiler: 20. -- OK 

Les applications de cette technique sont multiples. Par 
exemple, il arrive que la classe d'un objet ne puisse etre 
determinee completement a sa creation, ou qu'elle soit amenee a 
changer lors de la vie de l'objet. L'heritage dynamique permet 
de preciser la classe au fur et a mesure des connaissances 
acquises. Par exemple, dans un systeme graphique, des 
operations entre objets graphiques permettent de creer de 
nouveaux objets. Si un objet ainsi cree se trouve etre un objet 
regulier comme un rectangle, il peut changer de parent pour 
utiliser des methodes plus efficaces que celles definies sur un 
objet quelconque. Inversement, si un rectangle est transforme 
par une rotation, il devient un polygone, et doit changer de 
parent en consequence. 
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L'heritage dynamique est egalement utile lors de la mise au 
point d'un programme : pour observer un objet, on lui affecte 
comme parent un prototype qui trace les operations effectuees. 
On peut egalement tester une nouvelle implementation d'une 
classe en affectant, en cours d'execution, la nouvelle classe au 
parent d'un objet. 

Conclusion 

En abolissant les differences entre classe et instance, et en 
unifiant les champs et les methodes, les langages de prototypes 
ouvrent de nouvelles portes aux langages a objets a liaison 
dynamique. 

De facon assez surprenante, 1' implementation d'un langage 
de prototypes peut etre plus efficace que celle d'un langage tel 
que Smalltalk. Ceci necessite neanmoins la mise en ceuvre de 
techniques assez complexes, qui consistent pour l'essentiel a 
garder dans des caches les resultats des recherches de methodes 
pour optimiser les envois de messages, et a compiler differentes 
versions d'une methode pour des contextes d'appels differents. 

II n'en reste pas moins que les langages de prototypes sont 
des langages non types, done sans aucun controle de la validite 
d'un programme avant son execution. Autant il est envisageable 
d'ajouter des declarations de type dans un langage comme 
Smalltalk, autant cela est illusoire dans un langage de 
prototypes. En effet, la notion de type, qui correspond a celle de 
classe dans un langage de classes, n'a pas vraiment d'equivalent 
dans un langage de prototypes. Si Ton considere que le type 
d'un objet est son parent, tout typage statique est impossible car 
le type de l'objet peut changer durant sa vie. Par ailleurs, la 
structure d'un objet peut aussi changer par ajout de cases, de 
telle sorte qu'utiliser la structure d'un objet comme type est 
egalement impossible. 

En l'absence de moyens de verification statique des 
programmes, les langages de prototypes restent done reserves 
essentiellement au prototypage... 
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5.2 LANGAGES D'ACTEURS 

Les langages d'acteurs sont nes au MIT des travaux de Carl 
Hewitt dans les annees 70 avec le langage Plasma. Au debut des 
annees 80 Henry Liebermann, du MIT, a developpe ACT1, puis 
Akinori Yonezawa de lTnstitut de Technologie de Tokyo a 
introduit ABCL/1. 

L'objet des langages d'acteurs est de fournir un modele de 
calcul parallele fonde sur des entites independantes et 
autonomes communiquant par messages. Ces entites, appelees 
acteurs, sont composees d'un etat et d'un filtre. L'etat est 
constitue de variables locales et de references a d'autres acteurs, 
tandis que le filtre est une suite de modeles de messages 
auxquels l'acteur peut repondre. Chaque acteur est autonome : 
lorsqu'un message arrive, il verifie s'il correspond a un modele 
de son filtre. Si c'est le cas, l'acteur receveur execute le bloc 
d'instructions correspondant. Sinon, l'acteur delegue le 
message a un autre acteur, appele son mandataire (« proxy » en 
anglais). Ce mecanisme de delegation est similaire a celui des 
langages de prototypes, et nous ne reviendrons pas dessus. 

Les seules actions que peut effectuer un acteur sont V envoi de 
message, la creation de nouveaux acteurs, et sa transformation 
en un autre acteur. L'envoi de message est asynchrone : l'acteur 
ne se soucie pas de ce qu'il advient des messages qu'il envoie. 
Cet envoi asynchrone introduit le parallelisme de maniere 
naturelle : l'acteur continue son activite pendant que le message 
envoye est traite par son destinataire. Comme chaque acteur est 
sequentiel, il dispose d'une boite aux lettres dans laquelle sont 
stockes les messages qui arrivent pendant qu'il traite un 
message. 

La creation d' acteur est simple : un acteur peut creer un autre 
acteur, dont il specifie le mandataire, l'etat, et le filtre. La 
transformation d'un acteur est similaire a sa creation, a la 
difference que le nouvel acteur remplace le precedent, c'est-a- 
dire qu'il recupere sa boite aux lettres. Dans le modele introduit 
par Gul Agha, un acteur peut se transformer avant d' avoir 
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termine le traitement du message en cours. Dans ce cas, un 
acteur peut traiter plusieurs messages en parallele : il lui suffit, 
lorsqu'il recoit un message, de commencer par specifier son 
remplacant. Celui-ci pourra immediatement traiter le prochain 
message en attente. La possibilite de traiter des messages en 
parallele interdit de modifier l'etat de l'acteur. Ceci justifie la 
necessite de fournir explicitement un remplacant, qui est 
general ement une copie modifiee de l'acteur initial. 

L'envoi asynchrone de messages, s'il introduit naturellement 
le parallelisme, pose un probleme : comment envoyer un 
message et obtenir un resultat en retour ? La reponse consiste a 
transmettre une continuation avec le message. Une continuation 
designe l'acteur auquel le receveur d'un message devra 
transmettre sa reponse. Un acteur peut recevoir la reponse d'un 
message en se mentionnant comme continuation du message, 
mais il peut aussi mentionner un autre acteur qui saura traiter le 
resultat mieux que lui. 

Considerons par exemple les trois acteurs suivants : le lecteur 
lit des expressions au clavier, l'evaluateur evalue des 
expressions, et Vimprimeur affiche des valeurs. Le lecteur, 
lorsqu'il a lu une expression, envoie un message a l'evaluateur 
avec comme contenu l'expression a evaluer et comme 
continuation l'imprimeur. Ainsi, l'evaluateur transmettra 
directement le resultat a afficher a l'imprimeur. Dans un modele 
classique, le lecteur demanderait 1'evaluation a l'evaluateur, 
recevrait la reponse, et la transmettrait a l'imprimeur. 

Avec cet exemple, on pourrait penser que la continuation est 
inutile, puisque l'evaluateur envoie toujours sa reponse a 
l'imprimeur. Ce n'est pas le cas : l'evaluateur peut, si 
l'expression est complexe, s'envoyer des messages avec des 
sous-expressions a evaluer, en se specifiant comme sa propre 
continuation. Un autre acteur, qui lit par exemple dans un 
fichier, peut envoyer des messages a l'evaluateur avec comme 
continuation un imprimeur qui ecrit dans un fichier de sortie 
(figure 24). 
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eval: expr -» Imprimeur eval: expr -» self impr: resultat 




Figure 24 - Envois de messages avec continuations 



Programmer avec des acteurs 

Pour les exemples de cette section, nous avons adapte la 
syntaxe utilisee precedemment pour les prototypes. Un acteur 
est decrit par son nom, eventuellement suivi de son etat et de son 
filtre. Le filtre est un ensemble de couples <modele de message / 
action>. Un modele est un nom de message, avec des arguments 
et une continuation eventuelle, indiquee par une fleche « -» ». 
La creation d'acteurs et l'envoi de message ont la forme 
suivante : 

creer acteur (etatl, etat2, ... etatn) 

acteur msgl : arg1 msg2: arg2 ... msgn: argn -* continuation 

La figure 25 montre la representation d'un acteur : la fleche 
horizontale represente la vie de 1' acteur, les lignes brisees 
representent les envois de messages et les lignes pointillees 
representent les creations d'acteurs. 

Lorsqu'un acteur refoit un message, les modeles de son filtre 
sont compares au message re?u. Le modele qui ressemble le 
plus au message recu est choisi, et Taction correspondante est 
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* creation d'acteur 



Figure 25 - Representation d'un acteur 

activee. Si aucun modele ne convient, le message est transmis au 
mandataire, s'il y en a un ; sinon il y a erreur. 

Programmer avec des acteurs exige d'oublier tout ce que Ton 
sait de la programmation pour apprendre de nouvelles 
techniques specifiques du parallelisme. Prenons l'exemple 
simple de la factorielle, que chacun sait ecrire sous la forme 
d'une fonction recursive. Voici comment on realise le calcul 
d'une factorielle avec des acteurs : 

acteur factorielle 
filtre 

fact: 0 -> r [ r envoie: 1]. 

fact: i -> r [ cont «- creer mult (i, r). 

self fact: (i - 1) ->cont]. 

acteur mult 
etat val rec 
filtre 

envoie: v [ rec envoie: (v * val)]. 

L'acteur factorielle a deux modeles de messages, qui 
concernent tous les deux le message fact: avec une continuation. 
Le premier modele ne reconnait le message fact: que lorsque 
son argument est nul ; le second reconnait les autres messages 
fact:. L'acteur factorielle utilise un autre acteur, mult, pour 
l'aider a faire son calcul. L'etat de mult est constitue par un 
entier val et un acteur rec. Lorsqu'il recoit le message envoie:, il 
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fact: 3 -> res 




Figure 26 - Calcul de la factorielle 



renvoie le message envoie: a l'acteur rec, avec comme argument 
le produit de val et de la valeur recue. En d'autres termes, mult 
realise une multiplication et transmet le resultat a un acteur qui a 
ete specifie a sa creation. 

Lorsque l'acteur factorielle recoit un message lui demandant 
de calculer la factorielle de i et de transmettre le resultat a la 
continuation r, il commence par creer un acteur mult. Cet acteur 
multipliera par i la valeur qui lui sera transmise, et enverra le 
resultat a r. Ensuite, 1' acteur factorielle s'envoie un message lui 
demandant de calculer la factorielle de i-1 et de transmettre le 
resultat a l'acteur mult qu'il vient de creer. Cet acteur 
multipliera done la factorielle de i-1 par i, produisant le resultat 
escompte. Lorsque factorielle doit calculer la factorielle de 0, il 
envoie directement 1 a la continuation du message, ce qui 
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fact:3^M fact:4^r2 




Figure 27 - Calcul simultane de plusieurs factorielles 

termine le calcul en evitant l'envoi infini de messages de 
factorielle a lui-meme. 

La figure 26 visualise le calcul d'une factorielle. II y a 
creation d'un ensemble d'acteurs multi, un pour chaque etape 
du calcul. Ces acteurs sont inactifs jusqu'a reception du message 
envoie:. Le calcul se declenche en chaine lorsque factorielle 
envoie le message envoie: a mult 3. 

Le modele des acteurs nous a oblige a transformer la 
recursion en un ensemble d'acteurs qui represente le 
deroulement du calcul. Dans cet exemple, le calcul est 
strictement sequentiel. Neanmoins, l'acteur factorielle est 
capable de calculer plusieurs factorielles simultanement. En 
effet, observons ce qui se passe lorsqu'il recoit deux messages 
fact: (figure 27) : les deux calculs s'enchevetrent sans se 
melanger, car les messages transportent l'information suffisante 
pour le calcul qu'ils sont en train d'effectuer, sous la forme de 
continuations. 

II existe d'autres techniques de programmation avec des 
acteurs, que nous ne detaillerons pas ici, a part la jointure de 
continuations dont nous donnerons un exemple plus loin. 
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Envoi de messages 

Les langages d'acteurs apportent aux langages a objets une 
nouvelle vision de l'envoi de message. En fait, il n'y a que dans 
les langages d'acteurs que le terme d' envoi de message est 
correct : dans les autres langages, il s'agit d'invocation de 
procedures ou fonctions. La communication asynchrone, que 
nous avons utilisee jusqu'a present, n'est pas la seule disponible 
dans les langages d'acteurs. 

ABCL/1, par exemple, dispose de deux autres types de 
communication. Le premier, la communication synchrone, 
correspond a l'envoi de message avec attente de reponse. Dans 
ce cas la continuation est obligatoirement l'emetteur du 
message. La communication synchrone bloque l'emetteur 
jusqu'a reception du message. L'autre type de communication 
d' ABCL/1, la communication anticipee, permet de lever cette 
contrainte. Au lieu d'etre bloque dans l'attente de la reponse, 
l'acteur continue a fonctionner. Pour savoir si la reponse est 
disponible, il interroge le receveur du message. De cette facon, 
un acteur peut lancer des messages et collecter les reponses 
lorsqu'il en a besoin. 

Par ailleurs ABCL/1 offre deux modes de transmission des 
messages : le mode ordinaire, dans lequel les messages sont 
ajoutes dans la boite aux lettres du receveur, et le mode express. 
Lorsqu'un message express est envoye a un acteur, celui-ci est 
interrompu pour traiter ce message immediatement. S'il etait 
deja en train de traiter un message express, le message recu est 
mis dans la boite aux lettres des messages express, qui est 
toujours traitee avant la boite aux lettres des messages 
ordinaires. 

Les differents types de communication comme les modes de 
transmissions sont destines a faciliter la programmation avec des 
acteurs qui reste pourtant assez deroutante. Ainsi les messages 
express permettent de realiser des interruptions. Supposons 
qu'un acteur represente un tableau, et qu'un message permette 
de trouver un element dans le tableau. L'acteur decide de 
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repartir le travail entre plusieurs acteurs qui cherchent dans des 
parties disjointes du tableau. Des qu'un acteur a trouve 
l'element cherche, il est inutile pour les autres de poursuivre. 
L'acteur principal peut alors les interrompre par l'envoi d'un 
message express. Sans ce moyen, chaque acteur devrait 
decouper sa recherche en etapes elementaires, en s'envoyant des 
messages a lui-meme afin que le message d'interruption puisse 
etre pris en compte. 

Objets et acteurs 

On peut se demander dans quelle mesure les langages 
d'acteurs sont des langages a objets. Un acteur est un objet dans 
le sens ou il detient un etat et un comportement, mais, 
contrairement a un objet, il est actif et s'apparente plutot a un 
processus. Cela apparait clairement dans l'exemple de la 
factorielle : l'acteur est un objet qui calcule une factorielle, alors 
qu'un langage a objets classique verrait la factorielle comme un 
message envoye a un nombre. Les acteurs sont done aptes a 
representer un comportement ou un calcul, a l'instar des 
fonctions, ce que les objets sont incapables de faire. Mais les 
acteurs peuvent aussi representer un etat et des methodes 
associees, a l'instar des objets. De tels acteurs peuvent etre 
amenes a creer des acteurs de calcul pour repondre a un 
message. L'exemple ci-dessous illustre cet aspect. 

II s'agit de representer le jeu des Tours de Hanoi, et de le 
resoudre. Nous aurons besoin dans cet exemple de listes de type 
Lisp. Une liste est notee entre accolades. Nous supposons 
qu'une liste repond aux messages synchrones ajoute:, car et 
cdr, et qu'elle peut etre parcourue par le message repeter: qui 
prend en argument un bloc avec un argument. Nous denotons 
les messages synchrones en utilisant le symbole « J » comme 
continuation. Les messages synchrones peuvent retourner une 
valeur en utilisant l'operateur « T ». 

Nous allons utiliser un acteur Tour pour representer une tour, 
dont l'etat contient la pile des disques. Un acteur Hanoi 
representera l'ensemble du jeu. 
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acteur Tour 

etat pile sommet 

filtre 

Empiler: x [ pile en: sommet mettre: x J. 

sommet «- sommet + 1 ] 
Depiler [ sommet «- sommet - 1 ] 

Sommet [ tpile en: sommet J ] 

L'acteur Tour est ici une pile : nous n'avons pas insere le test 
qui compare la taille de l'objet empile avec le sommet courant. 
Ceci n'est pas important dans cet exemple, car la resolution par 
programme des Tours de Hanoi assure que les regies du jeu sont 
respectees. Sommet est un message synchrone qui retourne 
l'objet en sommet de pile. Nous avons suppose que l'acteur qui 
represente la pile sait repondre aux messages d'acces en: et 
en:mettre:. L'empilement utilise un message synchrone. 



acteur Hanoi 

etat gauche droite centre nd 
filtre 

Initialiser 

[ (1 a nd) repeter [ :i I gauche Empiler: (nd - i) ] ] 
deplacer: dep vers: arr 

[ arr Empiler: (dep Sommet J), dep Depiler ] 
Jouer 

[ jh *- creer JoueHanoi (self), 
jh deplacer: nd de: gauche vers: droite 
par: centre tag: 1 -> jh ] 

L'acteur Hanoi represente les Tours de Hanoi. Initialiser 
permet de mettre nd disques de tallies decroissantes sur la tour 
de gauche, deplacer -.vers: deplace un disque de la tour passee 
en premier argument vers celle passee en second argument ; il 
envoie le message synchrone Sommet a la tour de depart, empile 
la valeur retournee sur la pile d'arrivee, et depile la tour de 
depart. Jouer permet de lancer la resolution du jeu. Jouer cree 
un acteur JoueHanoi charge de resoudre le jeu. Rappelons 
l'algorithme sequentiel recursif qui resout les Tours de Hanoi : 
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-- deplacer n disques de la tour dep vers la tour arr 
-- en utilisant la tour intermediaire inter 
procedure Hanoi (n : entier; dep, arr, par : tour) { 
si n * 0 alors { 

Hanoi (n-1, dep, inter, arr); 

DeplaceDisque (dep, arr); 

Hanoi (n-1, inter, arr, dep); 

} 

} 

Avec les acteurs, la difficulte provient de la resolution parallele 
qui doit neanmoins produire une liste ordonnee de 
deplacements de disques. Selon la technique utilisee pour 
calculer la factorielle, et a l'aide d'une jointure de 
continuations, nous allons creer des acteurs qui representent les 
etapes du calcul, c'est-a-dire les sous-sequences de 
deplacements de disques. 

acteur JoueHanoi 
etat hanoi 
filtre 

deplacer: 1 de: D vers: A par: M tag: t -» cont 

[cont tag :t liste: {DA}] 
deplacer: n de: D vers: A par: M tag: t -» cont 
[ c «- creer Jointure (cont, t, {D A}, 0). 
self deplacer: n-1 de: D vers: M par: A tag: t*2 -» c. 
self deplacer: n-1 de: M vers: A par: D tag: t*2+1 -» c. 

] 

tag: t liste: listedepl 
[ listedepl repeter: 

[ :d I hanoi deplacer: (d car J) vers: (d cdr J) J] 

] 

Lorsqu'il recoit le message de resolution deplacer :de:vers: 
par:tag:, l'acteur JoueHanoi cree un acteur Jointure pour la 
jointure des continuations et s'envoie deux messages de 
resolution pour les deux sous-problemes. L'acteur de jointure 
est initialise avec le deplacement median et la continuation de 
JoueHanoi. II attend de recevoir les deux listes de deplacements, 
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les combine avec le emplacement median, et envoie le resultat a 
la continuation. Voyons maintenant l'acteur de jointure : 

acteur Jointure 

etat cont t listedepl attente 

filtre 

tag:t*2 liste: I 

[ listedepl «- I ajoute: listedepl J. self envoyer ] 
tag:t*2+1 liste: I 

[ listedepl «- listedepl ajoute: I J. self envoyer ] 
envoyer 

[ attente «- attente+1 . 

(attente = 2) siVrai: [ cont tag: t liste: listedepl ] ] 

Afin de combiner les listes de deplacements correctement, 
l'acteur de jointure doit pouvoir distinguer les deux listes qu'il 
recoit. Pour cela, les messages de resolution transportent une 
etiquette, appelee tag, qui numerate chaque resolution de facon 
unique : la resolution d'etiquette n declenche deux resolutions 
d'etiquettes 2*n et2*n + l. L'acteur de jointure est initialise 
avec l'etiquette de la resolution pour laquelle il a ete cree ; il 
peut done determiner l'origine des listes qu'il recoit et 
combiner les deplacements en consequence. Le message 
envoyer permet d'envoyer le deplacement final a la 
continuation, lorsque les deux sous-listes ont ete recues. 

Le message tagdiste: est envoye par JoueHanoi lorsqu'il a un 
seul disque a deplacer, et par Jointure lorsqu'il a combine les 
listes avec le deplacement median. II est recu soit par Jointure, 
auquel cas il contient les sous-listes de deplacements, soit par 
JoueHanoi lui-meme lorsque la resolution est terminee. Dans ce 
cas, la valeur de l'etiquette n'est plus utile. Lorsque JoueHanoi 
recoit la resolution finale, il enumere la liste des deplacements et 
envoie a Hanoi des messages de deplacement de disque 
deplace:vers:. Ces envois de messages sont synchrones pour 
assurer leur traitement dans l'ordre d'emission ; sinon, tout le 
travail precedent aurait ete inutile. 

L'exemple ci-dessous initialise un acteur Hanoi avec deux 
disques et lance une resolution, qui est illustree figure 28. 
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Jouer* 



tours 



/deplacer: 2 
'/ de: G vers: D par: C 
// tag: 1 -jh 




Jointure 

envoyer envoyer 

Figure 28 - Resolution des Tours de Hanoi 



tours *- creer Hanoi ( 

creer Tour (creer Tableau, 0), -- gauche 

creer Tour (creer Tableau, 0), -- centre 

creer Tour (creer Tableau, 0), -- droite 

2). - nd 

tours Initialiser, tours Jouer. 
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Le degre de parallelisme obtenu est assez faible : l'acteur de 
jointure fonctionne en parallele avec l'acteur JoueHanoi, mais 
c'est ce dernier qui fait l'essentiel du travail. Si Ton a n disques, 
il y a creation d'un seul acteur JoueHanoi, et de 2 n '^-l acteurs 
de jointure. Le temps de resolution est exponentiel en fonction 
de n, car l'acteur JoueHanoi s'envoie 2 n ~l messages qu'il traite 
sequentiellement. 

On pourrait augmenter le parallelisme en creant un acteur 
JoueHanoi a chaque decomposition du probleme. Pour n 
disques, il y aurait creation de 2*(n-l) acteurs JoueHanoi et de 
2 n ~l-l acteurs de jointure, et le temps de resolution serait 
lineaire en fonction de n. 

Conclusion 

La programmation avec un langage d'acteurs n'est pas 
simple, mais cela est vrai de tous les langages paralleles. Par 
contre, le modele des acteurs est facile a comprendre, ce qui 
n'est pas le cas de tous les modeles du parallelisme. 

Les langages d'acteurs sont plus proches des langages de 
prototypes que des langages de classes : ils utilisent la 
delegation, et la creation d'acteurs est proche du clonage. Cette 
ressemblance a des raisons historiques : la plupart des langages 
d'acteurs ont ete developpes au-dessus de Lisp, et ils sont 
contemporains des premiers langages de prototypes. II en 
resulte que les langages d'acteurs ne sont pas types, qu'ils n'ont 
pas de mecanismes de modularite, et qu'ils emploient la liaison 
dynamique. Les travaux sur les langages d'acteurs se sont 
focalises essentiellement sur la semantique de l'envoi de 
message, au detriment de ces autres aspects. 

Les langages d'acteurs et les langages de prototypes explorent 
des directions independantes qui se demarquent du modele strict 
des langages de classe. Ils permettent aussi de mieux 
comprendre l'essence de la programmation par objets, et Ton 
peut s'attendre a des retombees de ces travaux sur les langages a 
objets plus classiques. 
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PROGRAMMER 
AVEC PES OBJETS 

Ce chapitre presente quelques techniques usuelles de program- 
mation par objets et une ebauche de methodologie. II se termine 
par l'exemple complet des Tours de Hanoi, qui complete les 
classes Pile et Tour qui nous ont servi tout au long de ce livre. 
Bien que ce chapitre s' applique aux langages a objets types 
aussi bien qu'aux langages non types, l'exemple sera developpe 
dans le langage que nous avons utilise au chapitre 3. Un certain 
nombre de points seront done specifiques des langages types. 

Contrairement a la programmation imperative ou fonction- 
nelle classique, la programmation par objets est centree sur les 
structures de donnees manipulees par le programme. Le 
developpement d'un programme suit done les trois phases 
suivantes : 

• Identification des classes. 

• Definition du protocole des classes, e'est-a-dire les en-tetes 
des methodes publiques (visibles de l'exterieur des classes). 
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• Definition des champs et implementation des corps des 
methodes. Definition eventuelle de methodes privees 
(visibles uniquement de l'interieur des classes). 

L' identification correcte des classes, l'utilisation correcte de 
l'heritage et la bonne definition des protocoles sont 
determinants lorsque Ton souhaite creer des classes reutilisables. 
Aussi est-il important de comprendre et de pratiquer la 
programmation par objets avant de l'utiliser (pour des besoins 
professionnels), afin d'en percevoir clairement, par 
l'experimentation, les limites et les subtilites intrinseques. 

6.1 IDENTIFIER LES CLASSES 

L'identification des classes d'objets, qui semble souvent aisee, 
necessite en realite une bonne pratique de la programmation par 
objets. II faut eviter de definir trop peu de classes, qui 
correspondent a des fonctionnalites trop complexes, mais aussi 
de definir trop de classes, qui entretiennent des relations 
complexes entre elles. Le juste milieu est affaire d'experience. 
Les methodes de conception pour les langages a objets sont 
encore balbutiantes. Les methodes de conception par objets (a 
ne pas confondre avec les precedentes) sont plus repandues, 
mais elles ne sont pas toujours les mieux adaptees aux langages 
a objets. Certaines d'entre elles par exemple ne prennent pas en 
compte l'heritage. Une bonne approche consiste aussi a etudier 
les bibliotheques de classes fournies avec les langages ou 
disponibles pour ceux-ci. La bibliotheque de classes de 
Smalltalk est a ce titre tres instructive. Elle contient l'ensemble 
des classes qui implementent le systeme d'exploitation et 
l'environnement de programmation graphique du systeme 
Smalltalk. 

Nous proposons de distinguer plusieurs categories de classes. 
Sans etre exhaustive, cette classification donne une idee des 
differents roles que peut jouer une classe d'objets dans une 
application. 
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Les classes atomiques representent des objets autonomes, 
c'est-a-dire dont l'etat vu de l'exterieur ne depend pas d'autres 
classes. Par exemple, des classes d'objets graphiques (rectangles, 
cercles, etc.) ou geometriques (points, vecteurs, etc.) sont des 
classes atomiques. La classe des piles n'est pas une classe 
atomique car une pile renferme des objets auxquels on peut 
acceder. 

Les classes composees sont des classes dont les instances sont 
des assemblages de composants, ceux-ci etant accessibles de 
l'exterieur. Accessible signifie que Ton peut avoir connaissance 
des composants, meme si la classe controle ou limite leur acces. 
Par exemple, 1' acces aux composants peut etre en lecture seule, 
ou bien par l'intermediaire de noms symboliques (indice, 
chaine de caracteres). La classe des Tours de Hanoi est un 
exemple de classe composee ; dans l'exemple que nous 
donnons plus loin dans ce chapitre, nous verrons que 1' acces 
aux tours se fait de maniere symbolique, par un type enumere. 

Les classes conteneurs sont un cas particulier de classes 
composees. Une instance d'une classe conteneur (un conteneur) 
renferme une collection d'objets et fournit des methodes pour 
ajouter, enlever, rechercher des objets de la collection. Souvent, 
une classe conteneur fournit egalement un moyen d'enumerer 
les objets de la collection, souvent par l'intermediaire d'une 
classe active ou d'un iterateur (voir ci-dessous). La classe des 
piles est un exemple typique de classe conteneur. 

Les classes actives sont des classes qui representent un 
processus plutot qu'un etat. En Smalltalk, les blocs sont des 
classes actives, qui nous ont servi dans le chapitre 4 a definir des 
structures de controle. Un autre exemple courant de classe active 
sont les classes & iterateur s. Un iterateur est un objet qui permet 
d'enumerer les composants d'un autre objet. En general, l'objet 
itere est un conteneur. Une methode de 1' iterateur retourne le 
prochain objet de l'objet enumere. L'iterateur sert a stocker 
l'etat courant de l'enumeration, ce qui permet a plusieurs 
iterateurs d'etre actifs simultanement sur le meme objet. Un 
exemple d'iterateur est presente plus loin dans cette section. 
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Les classes abstraites sont des classes qui ne sont pas prevues 
pour etre instanciees, mais seulement pour servir de racine a une 
hierarchie d'heritage. En general, les classes abstraites n'ont pas 
de champs. Leurs methodes doivent etre redefinies dans les 
classes derivees, ou doivent appeler de telles methodes. Une 
classe abstraite sert a definir un protocole general qui ne prejuge 
pas de l'implementation des classes derivees. Un bon gage 
d'extensibilite d'un ensemble de classes est d'inserer des classes 
abstraites en des points strategiques de l'arbre d'heritage. 

Par exemple, la classe abstraite Collection decrite ci-dessous 
contient des methodes d'ajout, de retrait, et de recherche d'un 
element. Ces methodes doivent etre virtuelles si le langage 
impose la declaration explicite de la liaison dynamique, comme 
en C++. Les classes derivees {Ensemble, Liste, Fichier, etc.), 
doivent redefinir ces methodes en fonction de leur 
implementation de la collection. 

Collection = classe { 
methodes 

procedure Ajouter (Objet); 
procedure Retirer (Objet); 
fonction Chercher (Objet) : booleen; 
fonction Suivant (Objet) : Objet; 

} 

Une classe abstraite peut egalement contenir des methodes 
dont le corps est defini dans la classe abstraite, comme la 
methode AjouterSiAbsent ci-dessous : 

procedure AjouterSiAbsent (o : Objet) { 
si non Chercher (o) alors Ajouter (o); 

} 

En imposant un protocole sur ses classes derivees, une classe 
abstraite permet d'obtenir une plus grande homogeneite entre 
les classes. Par exemple, la classe Collection evite d'avoir une 
methode Ajouter dans Ensemble et une methode Inserer dans 
Liste : les deux methodes devront s'appeler Ajouter. 
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Une classe abstraite sert egalement a definir des classes 
generates (a defaut de generiques) : soit une classe abstraite A et 
une classe quelconque C ; en declarant dans C des champs ou 
des arguments de methodes de type A, on pourra utiliser C avec 
une plus grande gamme d'objets que si Ton avait utilise une 
classe concrete. A titre d'exemple, et a partir de la classe 
Collection definie ci-dessus, on peut construire une classe 
generale Iterateur, alors qu'en l'absence de classe abstraite, on 
serait contraint de definir une classe d'iterateurs pour chaque 
classe conteneur. 

Iterateur = classe { 
champs 

coll : Collection; 
courant : Objet; 
methodes 

procedure Initialiser (c : Collection) { 
c := coll; 

courant := coll.Suivant (NUL); 

} 

fonction Suivant () : Objet { 
o : Objet; 
o := courant; 

si o * NUL alors courant := coll.Suivant (courant); 
retourner o; 

} 

} 

Nous avons suppose ici que Collection.Suivant(NUL) retourne 
le premier objet de la collection, et que Collection. Suivant(o) 
retourne NUL lorsque o est le dernier element de la collection. 
NUL est un objet distingue qui sert ici a simplifier l'ecriture. 



Heritage ou imbrication ? 

Le principal probleme dans 1' identification des classes est le 
choix de la hierarchie d'heritage. II s'agit de determiner si une 
classe doit heriter d'une autre, et si oui de laquelle. Ici, les 
langages types sont plus contraignants que les langages non 
types car le choix de l'heritage determinera ce que Ton peut 
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faire des instances de la classe. Dans l'exemple de la classe 
Collection ci-dessus, si Ton definit une classe qui n'herite pas 
de Collection mais qui definit la methode Suivant, on ne pourra 
pas utiliser la classe Iterateur sur les objets de cette classe. Ce 
serait possible dans un langage non type, car tout ce que 
demande la classe Iterateur a l'objet itere est de repondre au 
message Suivant. En consequence, le choix de l'arbre 
d'heritage est a la fois plus difficile et plus determinant dans les 
langages a objets types. 

L'heritage est un mecanisme puissant, ce qui signifie qu'il 
peut etre utilise dans differents contextes. L'heritage peut servir 
a representer la specialisation et l'enrichissement : c'est ce pour 
quoi il est utilise le plus souvent. Ainsi, dans les chapitres 
precedents, nous avons fait heriter la classe Tour de la classe Pile 
car une tour est une pile « speciale ». Par contre, nous nous 
sommes gardes de faire heriter Pile d'une hypothetique classe 
Tableau, et nous avons prefere mettre le tableau dans la pile. 

La relation d'ordre entre les classes qui est induite par 
l'heritage doit nous inciter a utiliser l'heritage lorsque les 
protocoles des classes sont compatibles, et nous en dissuader 
lorsque seulement les structures des classes sont compatibles. Le 
protocole d'une classe est compatible avec celui d'une autre 
classe s'il est inclus dans celui-ci. De meme, la structure d'une 
classe est compatible avec celle d'une autre classe si elle est 
incluse dans celle-ci. C'est la compatibilite des protocoles qui 
permet d'utiliser l'heritage non seulement pour la specialisation 
(cas d'egalite), mais aussi pour l'enrichissement. Une pile et une 
tour ont le meme protocole : empiler, depiler, lire le sommet. 
Par contre un tableau a un protocole qui permet d'acceder a un 
element quelconque, ce qui est incompatible avec le protocole 
des piles. 

La semantique de l'heritage est telle qu'une classe derivee 
doit avoir un protocole compatible, mais aussi une structure 
compatible, puisque les champs de la classe de base sont herites. 
Cette contrainte est une source de problemes lorsque l'on 
definit la hierarchie des classes. En effet, le choix de la 
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hierarchic qui est initialement guide uniquement par la 
compatibilite des protocoles, peut etre invalide plus tard a cause 
d'une incompatibilite de structure. La solution consiste en 
general a creer des classes abstraites dont les classes de structures 
incompatibles sont des sous-classes. 

Considerons par exemple la classe Poly gone, avec comme 
methodes le dessin, la rotation et la translation. La classe 
Rectangle, qui represente des rectangles dont les cotes sont 
horizontaux et verticaux, est une candidate pour l'heritage, car 
son protocole est compatible. Mais Ton peut, pour des raisons 
d'efficacite, vouloir representer le rectangle par deux points 
diagonaux alors que le polygone necessite une liste de points. 
L'heritage devient impossible, et Ton doit introduire une classe 
abstraite Forme comme suit : 

Forme = classe { 
methodes 

procedure Dessiner (f : Fenetre); 

procedure Rotation (centre : Point; angle : reel); 

procedure Translation (v : Vecteur); 

} 



Polygone = classe Forme { 
champs 

points : Liste [Point]; 
methodes 

-- idem Forme 

} 



Rectangle = classe Forme { 
champs 

p1, p2 : Point; 
methodes 

-- idem Forme 



Le meme phenomene se reproduit si Ton veut definir une 
classe Carre. Celle-ci devrait en toute logique heriter de 
Rectangle, mais si Ton veut representer un carre par un point et 
une dimension, il faut definir une classe Quadrilatere, sous- 
classe de Forme, dont Rectangle et Carre sont des sous-classes. 
Cela conduit a alourdir inutilement la hierarchie d'heritage. 

Les utilisations de l'heritage autres que la specialisation et 
l'enrichissement sont generalement vouees sinon a l'echec, du 
moins a des solutions de compromis. L'utilisation de l'heritage 
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entre classes de structures compatibles mais de protocoles 
incompatibles, comme Tableau et Pile, peut etre acceptable si le 
langage permet de masquer la relation d' heritage du point de 
vue de l'inclusion de types. C'est le cas par exemple en C++ 
avec l'heritage prive. Dans les autres cas, il vaut mieux y 
renoncer, meme si cela alourdit la programmation. 

Heritage multiple 

L'heritage multiple est source de nombreux problemes. Nous 
avons deja evoque les conflits de noms et l'heritage repete. Mais 
l'heritage multiple pose aussi des problemes d'ordre 
semantique et methodologique. Selon notre approche de 
compatibilite de protocoles, on peut decider que l'heritage 
multiple est justifie si la sous-classe a un protocole compatible 
avec chacune de ses superclasses. Des conflits de protocoles 
peuvent apparaitre si une partie du protocole de la sous-classe 
est incluse dans les protocoles de plus d'une de ses 
superclasses : nous avons vu au chapitre 3 l'exemple de la 
methode Ecrire dans le cas de la classe TourGM heritant de Tour 
et Fenetre. Dans ce cas, il faut imperativement redefinir dans la 
sous-classe la partie du protocole qui cree des conflits. Si 
l'heritage multiple est justifie, le protocole redefini devrait faire 
appel aux protocoles des superclasses. 

Comme l'heritage simple, l'heritage multiple impose 
l'heritage de structure des classes parentes. Cet heritage de 
structure souleve le probleme de l'heritage repete : doit-on 
dupliquer les champs herites d'une meme classe par plusieurs 
chemins ? Bien que les langages fournissent divers mecanismes 
de controle, comme nous 1' avons vu, il est plus sain de ne pas 
utiliser l'heritage multiple dans une telle situation, car les risques 
sont grands de rendre la hierarchie des classes inutilisable. 
Notons toutefois que l'heritage repete ne provoquera pas de 
conflit d' heritage de structure si la classe heritee plusieurs fois 
est une classe abstraite sans champ : c'est la seule situation dans 
laquelle l'heritage repete est sans risque. 



Programmer avec des objets 129 



Dans le cas ou l'heritage multiple n'engendre pas de conflit 
de protocole, et si les classes heritees n'ont pas d'ancetre 
commun contenant des champs, alors on peut envisager 
l'utilisation de l'heritage multiple. On obtient alors une classe 
agglomeree, proche d'une classe composee qui aurait un champ 
par classe heritee. La difference entre classe agglomeree et 
classe composee est qu'une instance d'une classe agglomeree 
est d'un type compatible avec chacune des classes dont elle 
herite. Chaque classe heritee donne une facette differente a la 
classe agglomeree, et les conditions que nous avons imposees 
assurent l'independance de ces facettes. Le polymorphisme 
d'heritage sur une classe agglomeree revient a utiliser une 
instance de cette classe sous l'une de ses facettes. 

La similarite entre agglomeration et composition nous indique 
que, si Ton ne souhaite pas mettre en oeuvre l'heritage multiple 
pour l'une des raisons decrites ci-dessus, on peut lui substituer 
la composition. On ne dispose plus des facettes et de la facilite 
de programmation associee, mais on obtient un ensemble de 
classes plus facile a maitriser. 

Si la composition peut remplacer l'heritage multiple, 
l'heritage multiple ne doit pas remplacer la composition : ce 
n'est pas parce qu'une voiture est constitute d'un moteur, 
d'une carrosserie et de quatre roues qu'il faut faire heriter la 
classe Voiture de la classe Moteur, de la classe Carrosserie et 
quatre fois de la classe Roue ! C'est le protocole, et non pas la 
structure, qui determine l'heritage. 

6.2 DEFINIR LES METHODES 

Nous venons de voir comment les classes et l'arbre d'heritage 
sont definis. II est apparu, en particulier, que la notion de 
protocole etait cruciale dans la determination de l'heritage. 
Nous allons maintenant fournir des elements afin d'aider a la 
definition des protocoles, c'est-a-dire des methodes publiques 
des classes. Comme pour les classes, nous allons proposer une 
classification des methodes. 
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Les methodes d'acces servent a obtenir des informations sur le 
contenu d'un objet, et a modifier son etat, sans autre effet de 
bord. L'acces peut consister simplement a retourner ou affecter 
la valeur d'un champ, ou bien a effectuer un calcul qui utilise 
ou modifie la valeur des champs de l'objet. Dans ce dernier cas, 
on parlera plutot de methode de calcul. La plupart des langages 
de la famille Smalltalk engendrent automatiquement une 
methode d'acces en lecture et une methode d'acces en ecriture 
pour chaque champ. Ceci va a l'encontre de 1' encapsulation car 
toute classe est alors completement exposee a ses clients. 

Les methodes de construction permettent d'etablir des 
relations entre les objets. Les objets doivent en effet se connaitre 
afin de pouvoir s'envoyer des messages. Pour cela, les objets 
stockent des references vers d'autres objets, references qu'il est 
necessaire de maintenir. Determiner les bonnes methodes de 
construction est une tache delicate car les relations entre objets 
sont souvent complexes. 

Par exemple, une fenetre doit connaitre les objets graphiques 
qu'elle contient, et un objet graphique doit savoir dans quelle 
fenetre il se trouve. Deux problemes se posent : ou mettre la 
methode de construction, et comment etablir le lien, ici 
bidirectionnel, entre les objets. La methode d'ajout peut etre 
dans la classe des fenetres ou dans la classe des objets 
graphiques. On peut aussi decider de fournir les deux methodes. 
Dans tous les cas, la methode de l'une des classes devra faire 
appel a une methode de l'autre classe pour etablir le lien 
reciproque, comme dans cet exemple : 

procedure Fenetre. Ajouter (og : OGraphique) { 

- ajouter og dans la fenetre 
og.AjouteDans (moi); -- prevenir og 

} 

On voit ici que les deux classes Fenetre et OGraphique 
entretiennent un lien privilegie : si une autre classe appelle 
directement OGraphique AjouteDans , la relation de reciprocite 
entre la fenetre et l'objet graphique ne sera pas respectee et le 
systeme sera dans un etat errone. La seule solution est de faire 
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en sorte que seule la classe Fenetre puisse appeler 
OGraphique. AjouteDans . Les mecanismes de controle de 
visibilite tels que les amis de C++ et les listes d' exportation 
d'Eiffel permettent de realiser cela. 

Les methodes de controle utilisent le graphe des objets qui 
resulte de 1' application des methodes de construction pour 
realiser un calcul qui met en jeu plusieurs objets. Une methode 
de controle ne realise pas de calcul par elle-meme, elle 
determine les objets competents et leur retransmet toute ou 
partie du calcul. Par exemple, le reaffichage d'une fenetre est 
une methode de controle qui demande a chacun des objets de la 
fenetre de se redes siner. 

De la meme facon que pour les methodes de construction, les 
methodes de controle ont souvent besoin de faire appel a des 
methodes specifiques des objets qui ne doivent pas etre 
accessibles par d'autres clients. Dans l'exemple suivant, la 
methode de reaffichage d'une fenetre doit invoquer la methode 
privee InitDessin de la fenetre afin de mettre en place 
l'environnement necessaire pour que les objets puissent se 
redessiner : 

procedure Fenetre. Redessiner () { 

InitDessin (); -- mettre en place l'environnement 

pour chaque objet graphique o faire 
o. Redessiner (); 

} 

procedure OGraphique. Redessiner () { 

-- dessiner I'objet dans sa fenetre 

} 

Les methodes de dessin des objets graphiques doivent done 
etre visibles seulement par les classes capables de mettre en place 
cet environnement avant de les appeler, OGraphique. Redessiner 
ne doit done etre visible que de Fenetre. 

Les methodes de classe sont des methodes globales a une 
classe. Elles jouent le role de procedures et fonctions globales, 
mais beneficient des memes regies de visibilite que les methodes 
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normales. Dans les langages qui disposent de metaclasses, les 
methodes de classes sont definies dans celles-ci ; dans les autres 
langages, un mecanisme specifique permet de declarer des 
champs et des methodes de classe. Les methodes de classe sont 
utilisees pour acceder aux champs de classe pour controler le 
fonctionnement de l'ensemble des instances. Nous avons deja 
vu une utilisation de methodes de classe pour numeroter les 
instances d'une classe. Un autre exemple d'utilisation est le 
controle, par un champ et des methodes de classe, du type de 
traces emises par les methodes pour l'aide a la mise au point. 

Definir la visibility des methodes 

Les exemples precedents ont montre l'importance de la 
visibilite des methodes pour la securite de la programmation. 
Les langages non types n'offrent pas en general de controle de 
visibilite : toute methode, et meme tout champ (grace aux 
methodes d'acces creees automatiquement), est visible de toute 
classe. Au contraire, les langages types offrent differents 
domaines de visibilite. Cette distinction est revelatrice des 
differences dans l'utilisation des deux families de langages. 
Avec un langage type, on souhaite une encapsulation importante 
pour assurer une programmation plus sure en effectuant le 
maximum de controles de maniere statique. Les langages non 
types, de leur cote, sont souvent utilises pour le prototypage, et 
Ton souhaite alors un acces ouvert aux objets afin de faciliter le 
developpement incremental du prototype. 

II est souvent delicat de determiner le bon domaine de 
visibilite de chaque methode, meme lorsque le controle de 
visibilite est sophistique, comme dans Eiffel. En particulier, si 
Ton definit une classe reutilisable, les differentes utilisations de 
la classe conduiront en general a modifier l'interface, le plus 
souvent en rendant visible un plus grand nombre de methodes. 
Les domaines de visibilite dont on a besoin sont les suivants : le 
domaine prive a la classe, le domaine visible par les sous-classes, 
les domaines visibles par des classes privilegiees, et le domaine 
public a toute classe. 
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Les domaines visibles par des classes privilegiees sont les plus 
delicats a definir, car il faut eviter la proliferation des classes 
privilegiees d'une classe donnee. Dans un systeme bien concu, 
les classes fonctionnent par groupes, et chaque classe a pour 
classes privilegiees les autres classes du groupe. Cela circonscrit 
les dependances entre classes et facilite la reutilisation. 

La double distribution 

La semantique de l'envoi de message dans les langages a 
objets consiste a determiner la methode invoquee selon la classe 
de l'objet receveur du message. II arrive frequemment que le 
seul receveur ne suffise pas a determiner la bonne methode, car 
celle-ci peut dependre egalement de la classe effective des 
parametres du message. Dans les langages types, le polymor- 
phisme d'heritage permet en effet de passer comme parametres 
effectifs des objets d'une sous-classe de la classe declaree pour 
le parametre formel. Dans les langages non types, la classe des 
parametres n'entre pas en jeu dans la recherche de methode. 

Dans les deux cas, la technique de la double distribution 
(« double-dispatching ») permet de resoudre le probleme. Nous 
allons l'illustrer avec l'exemple suivant : deux classes abstraites 
Afficheur et OGraphique fournissent des methodes pour la 
representation d'objets graphiques sur des peripheriques. La 
methode de dessin d'un objet graphique sur un afficheur 
depend a la fois de la classe de l'afficheur et de celle de l'objet 
graphique. Avec les classes Fenetre et Imprimante, la double 
distribution de la methode de dessin se realise comme suit : 

Afficheur = classe { 
methodes 

procedure Dessiner (o : OGraphique); 

} 

Fenetre = classe Afficheur { 
methodes 

procedure Dessiner (o : OGraphique) { 
o.AfficherFenetre (moi); 

} 

} 
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Imprimante = classe Afficheur { 
methodes 

procedure Dessiner (o : OGraphique) { 
o.Afficherlmpr (moi); 

} 

} 

La methode Dessiner est redefinie dans chaque classe derivee, 
et appelle une methode de OGraphique, dont le nom encode la 
sous-classe emettrice : c'est la premiere etape de la double 
distribution. La deuxieme etape a lieu dans les sous-classes de 
OGraphique : chaque methode d'affichage sur un peripherique 
donne y est redefinie. 

OGraphique = classe { 
methodes 

procedure AfficherFenetre (aff : Fenetre); 
procedure Afficherlmpr (aff : Imprimante); 

} 

Rectangle = classe OGraphique { 
methodes 

procedure AfficherFenetre (aff : Fenetre) { 
... -- dessiner un rectangle dans une fenetre 

} 

procedure Afficherlmpr (aff : Imprimante) { 

... -- dessiner un rectangle sur une imprimante 

} 

} 

Cercle = classe OGraphique { 
methodes 

procedure AfficherFenetre (aff : Fenetre) { 
... - dessiner un cercle dans une fenetre 

} 

procedure Afficherlmpr (aff : Imprimante) { 
... -- dessiner un cercle sur une imprimante 

} 

} 



Programmer avec des objets 135 



Rectangle 




^Affichelmpr ysfr 



AfficheFenetre 
Affichelmpr 



Cercle 



AfficheFenetre 
Affichelmpr 



Fenetre 


C \ 

Imprimante 


^ Dessiner ^ 


^ Dessiner j 



Figure 29 - Double distribution 



La figure 29 illustre le mecanisme : la premiere distribution a 
lieu dans les sous-classes de Afficheur, et la deuxieme dans les 
sous-classes de OGraphique. Etant donne un objet graphique et 
un afficheur, c'est finalement l'une des methodes d'affichage 
des sous-classes de OGraphique qui sera appelee. 

Si Ton rajoute une sous-classe a Afficheur, il faut definir la 
methode Dessiner dans cette sous-classe ; il faut de plus ajouter 
la methode d'affichage correspondante dans OGraphique, et 
une implementation de cette methode dans chaque sous-classe 
de OGraphique. Si Ton ajoute une sous-classe a OGraphique, il 
faut implementer les methodes d'affichage sur chaque 
peripherique dans cette nouvelle classe. On peut noter que 
l'ajout d'une nouvelle classe d'objets graphiques peut se faire 
sans toucher aux classes d'afficheurs, tandis que l'inverse n'est 
pas vrai. Ce critere peut aider a choisir dans quel sens doit se 
faire la double-distribution. 

Si Ton a n sous-classes de Afficheur et p sous-classes de 
OGraphique, il faut implementer n methodes dans chaque sous- 
classe de OGraphique, soit n*p methodes. Ceci n'est pas 
surprenant puisque l'affichage depend du type d'afficheur et 
du type d'objet graphique. Mais il faut egalement implementer 
une methode de distribution pour chaque sous-classe de 
Afficheur, soit n methodes de plus. De par les services qu'elle 
rend, la double distribution est d'un cout acceptable. Notons 
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egalement que, dans un langage type qui autorise la surcharge 
des methodes (methodes de meme nom avec des listes de 
parametres differentes), les methodes de distribution peuvent 
porter le meme nom (ici se serait Afficher). 

6.3 REUTILISER DES CLASSES 

La reutilisation de classes est certainement l'un des avantages 
importants des langages a objets. La definition de classes 
reutilisables n'en est pas moins un travail difficile. On se trouve 
confronte a la definition de classes reutilisables lorsque Ton 
concoit une bibliotheque, c'est-a-dire un ensemble de classes 
fournissant un service particulier. Une telle bibliotheque 
contient en general des classes a utiliser telles quelles, et d'autres 
classes prevues pour etre derivees : c'est la reutilisation par 
heritage. La genericite offre egalement un moyen de 
reutilisation puissant, mais comme elle n'est pas disponible dans 
tous les langages, nous ne l'evoquerons pas dans cette partie. 

Lorsque Ton concoit une bibliotheque, on a une idee du type 
de reutilisation qui sera employe. Mais dans la pratique, les 
classes sont rarement reutilisees de la facon que Ton avait 
imagine : les besoins des utilisateurs ne correspondent pas 
exactement au service offert par la bibliotheque, ou bien le 
mode de reutilisation prevu ne s'adapte pas a l'application, ou 
bien encore les utilisateurs utilisent mal le mode de reutilisation 
prevu. La puissance d'une bibliotheque de classes sera d'autant 
plus grande qu'elle pourra etre utilisee de maniere non 
anticipee. Nous allons voir quelques techniques qui permettent 
d'atteindre cet objectif. 

Certaines classes peuvent etre prevues pour etre reutilisees 
directement, mais la plupart du temps, la reutilisation se fait par 
l'intermediaire de l'heritage. C'est notamment le cas pour les 
classes abstraites. La reutilisation par heritage consiste a 
redefinir des methodes de la classe de base, et a ajouter de 
nouveaux champs et de nouvelles methodes. C'est la 
redefinition qui pose bien sur le plus de problemes. La classe de 
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base doit definir quelles methodes doivent etre redefinies, celles 
qui peuvent etre redefinies, et celles qui ne doivent pas l'etre. 
Ces trois types de methodes dependent du protocole de la classe 
de base. Sans cette information, on ne peut pas reutiliser la 
classe de base correctement. 

Une technique particulierement sure consiste a autoriser 
seulement la redefinition de methodes privees, comme le montre 
l'exemple suivant : 



PileAbstraite = classe { 

methodes privees 

procedure Ajouter (o : Objet); -- a redefinir 
procedure Retirer (); -- a redefinir 

fonction EstVide () : booleen; -- a redefinir 
fonction Dernier : Objet; -- a redefinir 

procedure PileVide (); - a redefinir 

methodes -- methodes publiques 
procedure Empiler (o : Objet) { 
Ajouter (o); 

} 

procedure Depiler () { 

si non EstVide () alors Retirer (); 

} 

fonction Sommet : Objet { 
si non EstVide () 

alors retourner Dernier () 

sinon { PileVide (); retourner NUL; } 

} 

} 

Parce qu'il est tres simple, cet exemple est un peu caricatural. 
II montre neanmoins que, en interdisant la redefinition des 
methodes publiques, on ne peut creer une sous-classe qui ne 
respecte pas la semantique d'une pile. La methode PileVide 
permet de redefinir la facon de signaler ou de traiter l'erreur 
qui consiste a acceder au sommet d'une pile vide. 
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De maniere generale, le protocole public assure les controles 
de maniere a respecter la semantique de la classe, tandis que le 
protocole prive definit les operations atomiques a definir dans 
chaque sous-classe. Cela n'empeche pas, le cas echeant, de 
redefinir une methode du protocole public dans une sous-classe, 
en particulier pour des raisons d'efficacite. 

Classes dependantes 

L'utilisation de classes composees ou agglomerees conduit en 
general a des ensembles de classes qui sont prevus pour 
fonctionner ensemble. La reutilisation de ces classes doit se faire 
en les derivant en parallele, ce qui pose des problemes 
specifiques. Reprenons l'exemple des classes Fenetre et 
OGraphique. Une fenetre contient une liste d'objets a afficher 
et un objet graphique contient la fenetre dans laquelle il 
s'affiche. La derivation parallele a generalement pour objectif 
de definir deux nouvelles classes qui, comme leurs classes de 
base, doivent fonctionner ensemble. 

Par exemple, on cherche a definir les classes Fenetre3D et 
OGraphique3D pour l'affichage d'objets a trois dimensions : 

Fenetre3D = classe Fenetre { 
methodes publiques 

procedure Ajouter (o : OGraphique); -- heritee 

} 

OGraphique3D = classe OGraphique { 
methodes privees 

procedure AjouteDans (f : Fenetre); -- heritee 

} 

Une fenetre a trois dimensions ne peut contenir que des objets 
graphiques a trois dimensions. Malheureusement, ceci n'est pas 
reflete par les methodes heritees : la procedure Fenetre. Ajouter 
prend un objet graphique quelconque en parametre, de meme 
que la procedure OGraphique .AjouteDans prend une fenetre 
quelconque en argument. 
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Dans les langages non types, il est facile de tester la classe 
effective d'un objet, comme nous l'avons montre au chapitre 4 
avec la classe HP He. Par contre, il n'y a pas de solution 
satisfaisante a ce probleme dans les langages types. II faudrait 
redefinir la methode Aj outer avec un parametre de type 
OGraphique3D. 

Certains langages, notamment Eiffel, autorisent la redefinition 
d'une methode dans une sous-classe avec des parametres dont 
les types sont inclus dans les types des parametres corres- 
pondants dans la classe de base. Malheureusement, le controle 
de type ne peut plus etre realise statiquement, ce qui fait d 'Eiffel 
un langage faiblement type, comme le montre cet exemple : 



V = classe U { 

procedure h (); 

} 

B = classe A { 

procedure f (p : V) { 

ph(); 

} 

} 



U = classe { 

procedure g (); 

} 

A = classe { 

procedure f (p : U) { 

p-g 0; 

} 

} 

a:A;b:B;u:U; 

a = b; -- polymorphisme d'inclusion 
a.f (u); -- la liaison dynamique appelle B.f 

Dans cet exemple, la methode /est redefinie dans la classe B, 
avec un parametre appartenant a une sous-classe de celui declare 
pour A.f. L'appel a.f(u) est correct du point de vue du typage 
statique. A l'execution, a contient un objet de classe B done, par 
liaison dynamique, e'est B.f qui sera appelee. Malheureusement, 
B.f attend un parametre de type V alors que Ton a passe un 
parametre de type U. Pour eviter une erreur a l'execution, le 
compilateur doit engendrer du code pour controler le type 
effectif des objets a l'execution. 

Dans les langages qui n'offrent pas le mecanisme d'Eiffel, la 
seule solution sure consiste a fournir une methode qui permette 
de connaitre et de tester la classe d'un objet. Cela revient a 
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definir des objets qui representent des classes, comme les 
metaclasses des langages a objets de la famille Smalltalk. 

Dans tous les cas, la derivation parallele oblige a abandonner 
l'idee d'un typage statique, ce qui implique une attention plus 
grande lors de la conception du systeme pour limiter les 
situations qui font intervenir le controle de types dynamique. 

6.4 EXEMPLE : LES TOURS DE HANOI 

Nous presentons dans cette section l'exemple complet des 
Tours de Hanoi. Nous partons de la classe Tour definie dans le 
chapitre 3, et nous definissons la classe Hanoi qui represente le 
jeu des Tours de Hanoi. 

TourPos = (gauche, centre, droite); 
Hanoi = classe { 
champs 

tours : tableau [TourPos] de Tour; 
methodes 

procedure Construire (); 
procedure Initialiser (n : entier); 
procedure Deplacer (de, vers : TourPos); 
procedure Jouer (de, vers, par : TourPos; n : entier); 

} 

Le type TourPos sert a identifier les trois tours. Hanoi est une 
classe composee offrant un acces controle a ses composants. Les 
corps des methodes sont les suivants : 

procedure Hanoi. Construire (){ 
tours [gauche] := allouer (Tour); 
tours [centre] := allouer (Tour); 
tours [droite] := allouer (Tour); 

} 

procedure Hanoi. Initialiser (n : entier) { 
tours [gauche] . Initialiser (n); 
tours [centre] . Vider (); 
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tours [droite] . Vider (); 

} 

procedure Hanoi. Deplacer (de, vers : TourPos) { 
d : entier; 

d := tours [de] . Sommet (); 

si tours [vers] . PeutEmpiler (d) alors { 

tours [de] . Depiler (); 

tours [vers] . Empiler (d); 
} sinon 

erreur.Ecrire ("Deplacer : coup impossible"); 



procedure Hanoi.Jouer (de, vers, par : TourPos; n : entier) { 
si n > 0 alors { 

Jouer (de, par, vers, n -1); 
Deplacer (de, vers); 
sortie. Ecrire (de, " -> ", vers); 
Jouer (par, vers, de, n -1); 

} 

} 

Les objets erreur et sortie sont des objets globaux qui 
permettent d'afficher des messages a l'ecran. allouer permet de 
creer un objet dynamiquement (comme le new de Pascal). 

On peut utiliser le jeu des Tours de Hanoi comme suit : 

hanoi : Hanoi; 
hanoi.Construire (); 
hanoi. Initialiser (4); 
hanoi. Deplacer (gauche, centre); 
hanoi. Deplacer (gauche, droite); 
hanoi. Deplacer (droite, centre); 
-> jouer : coup impossible 

La resolution automatique du jeu se fait de la facon suivante : 

hanoi. Initialiser (3); -- revenir a la position initiale 
hanoi.Jouer (); 
gauche -> centre 
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gauche -> droite 
centre -> droite 

Les Tours de Hanoi graphiques 

Essayons maintenant d'utiliser la classe TourG definie au 
chapitre 3 pour definir la classe HanoiG des Tours de Hanoi 
graphiques. II nous suffit de redefinir la methode Construire 
pour allouer des tours graphiques au lieu de tours normales. 
Comme les tours graphiques necessitent une fenetre pour 
l'affichage, nous allons ajouter un champ dans le nouvelle 
classe. 

HanoiG = classe Hanoi { 
champs 

f : Fenetre; 
methodes privees 

procedure ConstruireTour (t : TourPos; x, y : entier); 
methodes 

procedure Construire (); 

} 

procedure HanoiG. ConstruireTour (t : TourPos; x, y : entier) { 
tours [t] := allouer (TourG); 
tours [t] . Placer (f, x, y); 

} 

procedure HanoiG. Construire () { 
f := allouer (Fenetre); 
ConstruireTour (gauche, 10, 100); 
ConstruireTour (centre, 50, 100); 
ConstruireTour (droite, 90, 100); 

} 

La methode ConstruireTour est une methode auxiliaire de 
Construire. Elle doit done etre privee. 

L'exemple d'utilisation de la classe Hanoi s'applique a un 
objet de la classe HanoiG. Toutefois, les deplacements des 
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disques ne seront pas visualises graphiquement. Si Ton veut 
ajouter cette animation, il faut redefinir la methode Deplacer. 

procedure HanoiG. Deplacer (de, vers : TourPos) { 
Hanoi. Deplacer (de, vers); 
-- animation 

} 

Cette solution n'est pas satisfaisante car si le deplacement est 
invalide, Hanoi. Deplacer emet un message d'erreur, et 
1' animation ne devrait pas avoir lieu. Le seul moyen de tester la 
validite du deplacement dans HanoiG. Deplacer est de repeter le 
code de Hanoi. Deplacer, ce qui rend la classe derivee HanoiG 
dependante de 1' implementation de la classe Hanoi. 

Un meilleure solution consiste a modifier la classe Hanoi pour 
la rendre plus flexible du point de vue de la reutilisation, comme 
nous l'avons illustre avec la classe PileAbstraite de la section 6.3 
ci-dessus. Definissons pour cela une methode privee Bouger, 
appelee depuis Deplacer lorsque le deplacement est licite : 

Hanoi = classe { 

methodes privees 

procedure Bouger (d : entier; de, vers : TourPos); 
methodes 

procedure Deplacer (de, vers : TourPos); 

} 

procedure Hanoi. Deplacer (de, vers : TourPos) { 
d : entier; 

d := tours [de] . Sommet (); 
si tours [vers] . OK (d) alors { 

tours [de] . Depiler (); 

tours [vers] . Empiler (d); 

Bouger (d, de, vers); -- notifier le deplacement 



144 Les langages a objets 



}sinon 

erreur.Ecrire ("Deplacer : coup impossible"); 

} 

procedure Hanoi. Bouger (d : entier; de, vers : TourPos) { 
-- rien par defaut 

} 

La classe HanoiG devient : 

HanoiG = classe Hanoi { 
champs 

f : Fenetre; 
methodes privees 

procedure ConstruireTour (t : TourPos; x, y : entier); 

procedure Bouger (d : entier; de, vers ; TourPos); 
methodes 

procedure Construire (); 

} 

procedure HanoiG. Bouger (d : entier; de, vers : TourPos) { 
-- animation du disque d de la tour de vers la tour vers 

} 

II n'est plus necessaire de redefinir Deplacer. On a rendu la 
classe extensible en definissant une methode privee (ici Bouger) 
qui notifie les classes derivees d'un changement d'etat 
significatif. II faut bien reconnaitre que, sans la tentative de 
derivation, ceci ne serait pas apparu spontanement. L'ecriture de 
classes reutilisables necessite done une connaissance a priori des 
contextes de reutilisation. 



6.5 CONCLUSION 

Ce chapitre nous a montre les possibilites mais aussi les limites 
des langages a objets. Par rapport aux autres langages, les 
langages a objets favorisent la modularite et la reutilisation, sans 
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pour autant resoudre completement les problemes lies a ces 
aspects. 

Les exemples de developpement d' applications avec un 
langage a objets ont montre que les classes aident a maitriser de 
gros systemes, a condition de les specifier soigneusement, et de 
s' adapter au langage en faisant des concessions au modele ideal 
des objets. En d'autres termes, les langages a objets sont un outil 
puissant et general, mais ne sont pas la panacee : un probleme 
ne s'est jamais resolu par la seule vertu des objets. 
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